Wyrok KIO 1951/19 z 17 października 2019

Zamawiający, Niepubliczny Zakład Opieki Zdrowotnej Szpital im. profesora Zbigniewa Religi w Słubicach Sp. z o.o. prowadzi postępowanie o udzielenie zamówienia publicznego w trybie przetargu nieograniczonego pn. „Rozbudowa i wdrożenie usług i aplikacji w zakresie e-zdrowia w Szpitalu im. prof. Z. Religi w Słubicach Sp. z o.o.” Ogłoszenie o zamówieniu opublikowano w Dzienniku Urzędowym Unii Europejskiej w dniu 18 września 2019 r. pod numerem: 4378452019-PL Specyfikacja istotnych warunków zamówienia została zamieszczona przez Zamawiającego na stronie internetowej w dniu 18.09.2019 r.

Wykonawca Comarch Healthcare S.A. z siedzibą w Krakowie wniósł odwołanie wobec treści postanowień specyfikacji istotnych warunków zamówienia oraz ogłoszenia o zamówieniu, zarzucając Zamawiającemu naruszenie art. 29 ust. 1 i 2 w zw. z art. 7 ust. 1 ustawą z dnia 29 stycznia 2004 r. - Prawo zamówień publicznych (tj. Dz. U. z 2019 r., poz.

1. zwaną dalej „Pzp”, poprzez opisanie przedmiotu zamówienia i sformułowanie treści specyfikacji istotnych warunków zamówienia w sposób niejednoznaczny, niewyczerpujący, bez uwzględnienia wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty, a także w sposób, który mógłby naruszać uczciwą konkurencję, a w szczególności poprzez:
2. zaniechanie określenia w SIWZ wszystkich wymaganych danych dotyczących obowiązku dokonania przez wykonawcę integracji z systemami obecnie wykorzystywanymi przez Zamawiającego,
3. zaniechanie określenia w SIWZ wszystkich wymaganych danych dotyczących obowiązku dokonania przez wykonawcę migracji danych w przypadku podjęcia decyzji o wymianie systemu,
4. żądanie dostarczenia oprogramowania pracującego w modelu dwuwarstwowym i trójwarstwowym, a więc sporządzenie opisu przedmiotu zamówienia w sposób nieuzasadniony potrzebami Zamawiającego, ograniczający uczciwą konkurencję i zasadę równego traktowania wykonawców, tj. poprzez umożliwienie złożenia oferty tylko przez wąską grupę podmiotów, podczas gdy brak jest jakiegokolwiek uzasadnienia dla takiego żądania,
5. wprowadzenie wymogu obsługi skrótów klawiaturowych oraz wymogu, iż zakres używanych skrótów klawiszowych musi być spójny między wersjami architektury systemu, a więc sporządzenie opisu przedmiotu zamówienia w sposób nieuzasadniony potrzebami Zamawiającego, ograniczający uczciwą konkurencję i zasadę równego traktowania wykonawców, tj. poprzez umożliwienie złożenia oferty tylko przez wąską grupę podmiotów, podczas gdy brak jest jakiegokolwiek uzasadnienia dla takiego żądania,
6. wprowadzenie wymogu przenoszenia sesji, rozumianego w ten sposób, iż system wyświetla na ekranie, z którego sesja została przeniesiona, informację dokąd przeniesiono sesję, a więc sporządzenie opisu przedmiotu zamówienia w sposób nieuzasadniony potrzebami Zamawiającego, ograniczający uczciwą konkurencję i zasadę równego traktowania wykonawców, tj. poprzez umożliwienie złożenia oferty tylko przez wąską grupę podmiotów, podczas gdy brak jest jakiegokolwiek uzasadnienia dla takiego żądania,
7. wadliwie sporządzony Scenariusz dotyczący próbki:

a. (Dodatek 7 do SIWZ pkt 9) zgodnie z którym dopuszcza się nagrywanie przez Zamawiającego przebiegu demonstracji kamerą video i/lub innymi środkami audiowizualnymi, a przedstawiciele wykonawcy nie będą upoważnieni do rejestracji przebiegu demonstracji w postaci audiovideo, co narusza także zasadę jawności postępowania (art. 8 Pzp),

b. (Dodatek do SIWZ pkt 14 i 15) zgodnie z którym Zamawiający ma prawo żądać zmodyfikowania wartości parametrów bądź danych wprowadzanych do systemu na wartości podane przez niego, celem sprawdzenia czy demonstrowana funkcjonalność nie jest przez wykonawcę symulowana oraz zadawać pytania wykonawcy w zakresie prezentowanych wymogów funkcjonalnych, mające na celu ustalenie czy dana funkcjonalność jest rzeczywiście realizowana, bez wskazania, iż czas realizacji uprawnień przez Zamawiającego nie będzie wliczany do czasu trwania prezentacji próbki, czym Zamawiający naruszył także § 13 pkt 1 rozporządzenia w sprawie rodzajów dokumentów, jakich może żądać zamawiający od wykonawcy w postępowaniu o udzielenie zamówienia,

1. zbyt krótki termin realizacji umowy, a więc sporządzenie opisu przedmiotu zamówienia w sposób nieuzasadniony potrzebami Zamawiającego, ograniczający uczciwą konkurencję i zasadę równego traktowania wykonawców, tj. poprzez umożliwienie złożenia oferty tylko przez wąską grupę podmiotów, czym Zamawiający naruszył art. 36 ust. 1 pkt 4 Pzp.

Odwołujący wyjaśnił, że jest podmiotem zdolnym do wykonania zamówienia, posiadającym odpowiednie kompetencje i doświadczenie, jednak poprzez sformułowanie przez Zamawiającego postanowień SIWZ w sposób naruszający przepisy ustawy może być pozbawiony możliwości złożenia oferty i uzyskania zamówienia.

Odwołujący podkreślił, że Zamawiający, jako podmiot nadający kształt specyfikacji istotnych warunków zamówienia i zawieranej umowie, nie jest w swych uprawnieniach nieograniczony - związany jest podstawowymi dla prawa zamówień publicznych zasadami, takimi jak zasada proporcjonalności i uczciwej konkurencji. Każde postanowienie odnoszące się do przedmiotu zamówienia, szczególnie jeżeli ogranicza konkurencję lub narusza zasadę proporcjonalności, powinno być uzasadnione z punktu widzenia uzasadnionych potrzeb Zamawiającego. Formułując wymogi co do przedmiotu zamówienia, Zamawiający powinien przestrzegać reguły proporcjonalności, tj. przyjęcia takich warunków, które uzasadnione są przedmiotem zamówienia, w tym w szczególności jego rozmiarem, złożonością i innymi istotnymi warunkami jego realizacji. Zamawiający winien móc udowodnić, że postawienie określonego wymogu jest uzasadnione.

Odwołujący podniósł, że w tym przypadku sposób sformułowania dokumentacji przetargowej (w szczególności opisu przedmiotu zamówienia i umowy) sprawiają, że jedynym podmiotem, który jest w stanie zidentyfikować, co w ogóle jest przedmiotem zamówienia i jakie obowiązki będą ciążyły na wykonawcy, którego oferta została wybrana jest dostawca oprogramowania HIS (czyli Szpitalnego Systemu Informatycznego) obecnie funkcjonującego u Zamawiającego. Taki sposób sformułowania dokumentacji przetargowej jest niezrozumiały w sytuacji, w której projekt jest dofinansowany ze środków Unii Europejskiej, w którym sankcją za niekonkurencyjne przeprowadzenie postępowania jest korekta i zwrot środków unijnych.

Zdaniem Odwołującego, istnieje duże prawdopodobieństwo, iż całość działań Zamawiającego w toku realizacji projektu finansowanego ze środków unijnych (począwszy od przygotowania dokumentacji projektowej i założeń projektu) ma cechy niegospodarności.

ZARZUT I - ZANIECHANIE UDOSTĘPNIENIA INFORMACJI DOT. INTEGRACJI Zgodnie z treścią Dodatku 2.3. do SIWZ stanowiącego Opis zakresu czynności w przypadku wymiany sytemu, Zamawiający dopuszcza formalnie możliwość dostarczenia innego rozwiązania informatycznego, w miejsce obecnie funkcjonującego w szpitalu oprogramowania HIS, nakładając na potencjalnego wykonawcę dodatkowo obowiązek zachowania ciągłości pracy organizacji Zamawiającego, z uwzględnieniem m.in. obowiązku integracji z systemami, z którymi współpracuje obecnie wykorzystywany przez Zamawiającego systemu HIS wraz z odtworzeniem historii przesłanych danych.

Zamawiający wyspecyfikował w treści Dodatku 2.3. systemy będące przedmiotem integracji, nie wprowadzając żadnych dodatkowych informacji dotyczących interfejsów integracyjnych do wymiany danych z posiadanym systemem, które to informacje są niezbędne do zrealizowania integracji - obowiązkowej w przypadku wymiany systemu HIS.

Odwołujący podkreślił, że z treści Dodatku 2.1. sekcja I. 4. 5. Dostawa, instalacja, konfiguracja i wdrożenie Oprogramowania aplikacyjnego ppkt. 5) wynika, że Zamawiający wymaga, aby dostarczane oprogramowanie aplikacyjne było zainstalowane w taki sposób, aby zachować w całości dotychczasowe integracje z oprogramowaniem posiadanym przez Zamawiającego, w szczególności obejmujące zakres integracji, interfejsy integracji oraz model wymiany danych.

Sposób sformułowania powyższego zapisu wskazuje na brak jakiegokolwiek opisu dotychczasowych integracji z oprogramowaniem HIS, w szczególności brak jest opisów zakresu integracji, interfejsów integracji oraz modelu wymiany danych. Wykonawca nie ma wiedzy, co właściwie ma zachować - Zamawiający nałożył na niego jedynie obowiązek zachowania bliżej nieokreślonych relacji dotychczasowego systemu HIS z innymi programami komputerowymi, nie zapewniając przy tym wykonawcy konkretnych informacji, które mają wpływ na decyzję co do udziału w postępowaniu oraz szacunek, na którym wykonawca opiera cenę swojej oferty.

Odwołujący wskazał, że obowiązkiem Zamawiającego jest sformułowanie treści SIWZ w sposób wyczerpujący, precyzyjny i jednoznaczny. Tym samym niedopuszczalnym jest kreowanie sytuacji, w której potencjalny wykonawca zobowiązany jest do antycypowania, co Zamawiający ma na myśli. Sytuacja ta odzwierciedla się w treści Dodatku 2.2. Wymagane funkcjonalności :

• Wymagania ogólne - Architektura HIS - pkt. 22 - Elektroniczna dokumentacja medyczna - pkt. 41 Zamawiający w przywołanych powyżej punktach nie wprowadza definicji „innych aplikacji działających na stacji klienckiej”, ani „innych systemów”. Nie wiadomo, ile jest tych aplikacji czy systemów, kto jest ich producentem etc. Zgodnie z powyższą treścią Zamawiający może wymagać od wykonawcy dostarczenia i zintegrowania oprogramowania aplikacyjnego, dostarczanego w ramach niniejszego zamówienia z każdą aplikacją działającą aktualnie, bądź w przyszłości, na stacji klienckiej (w tym oprogramowaniem innych producentów), na których zakres wykonawca nie ma wpływu.

Zamawiający, poprzez niewskazanie konkretnych opisów, tj. nazw producentów, modeli, opisów technicznych posiadanych i wykorzystywanych „innych aplikacji” prowadzi do sytuacji, w której Odwołujący nie jest w stanie przewidzieć i zaplanować kosztów oferty. Tym samym Zamawiający nie zawarł wszystkich wymagań mogących mieć wpływ na sporządzenie oferty. Ponadto potencjalny wykonawca nie jest w stanie nawet przewidzieć czy wymienione w przywołanym powyżej pkt. 21 systemy w ogóle posiadają możliwość integracji z nowoczesnymi systemami klasy HIS. Brak dostarczenia przez Zamawiającego niezbędnych danych dotyczących integracji z posiadanym oprogramowaniem (zarówno wyspecyfikowanym w Dodatku 2.3. jak i wymienionym „innym oprogramowaniem” w Dodatku 2.2. Wymagania ogólne - Architektura HIS pkt. 22; „innym systemem” w Dodatku 2.2. Elektroniczna dokumentacja medyczna - pkt. 41) powoduje, iż na chwilę obecną integracja jest w istocie niemożliwa. Wykonawca na ten moment nie jest w stanie rzetelnie oszacować zakresu i kosztu niezbędnych czynności, które są wymagane do złożenia ofert w postępowaniu przetargowym.

Odwołujący podkreślił, że jedynym wykonawcą mającym pełną wiedzę dotyczącą niezbędnej integracji jest dostawca aktualnie eksploatowanego przez Zamawiającego systemu HIS, co może postawić takiego wykonawcę w sytuacji uprzywilejowanej wobec reszty wykonawców z uwagi na fakt, że aby sprostać wymaganiom Zamawiający musiał dokonać integracji już wcześniej i posiada przygotowanie interfejsy wymiany danych ze wskazanymi systemami. Opis przedmiotu zamówienia w oczywisty sposób uprzywilejowuje obecnego dostawcę HIS, który jako jedyny jest w stanie rozpoznać intencje Zamawiającego oraz ma wiedzę na temat architektury systemów, które mają podlegać integracji oraz czynności, które należy podjąć, aby spełnić ww. obowiązek. W niniejszym postępowaniu Zamawiający nie podjął nawet próby opisu przedmiotu zamówienia w zakresie integracji - stawiając wymóg jej dokonania, co w rażący sposób narusza zasadę równego traktowania wykonawców oraz uczciwej konkurencji.

Zgodnie z treścią wyżej wskazanych postanowień SIWZ, Zamawiający opisał przedmiot zamówienia w sposób niewyczerpujący, bez uwzględnienia wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty. W SIWZ brak jest informacji dotyczących szczegółowych danych technicznych niezbędnych do przeprowadzenia integracji wraz z dokumentacją dotyczącą sposobu komunikacji tych systemów, tj. brak w SIWZ:

• dokumentacji opisującej zdolność komunikacji systemów, z którymi ma być przeprowadzona integracja, sposobu komunikacji, opisu transakcji, konstrukcji pliku komunikatu transakcji, pełnej dokumentacji technicznej umożliwiającej integrację, brak opisanych widoków baz danych i procedur składowych systemów innych producentów;
• opisu interfejsów wymiany danych systemów, z którymi ma nastąpić integracja wraz z dokumentacją - w szczególności w przypadku, w którym Zamawiający powołuje się na konieczność zachowania w całości dotychczasowych integracji;
• opisu zakresu integracji; - opisu struktury danych systemów, z którymi ma się integrować dostarczany system.

Brak precyzyjnego opisania sposobu integracji systemu wykonawcy z systemami Zamawiającego uwidacznia się również w odniesieniu do ewentualnego wdrożenia przez

Zamawiającego nowych wersji użytkowanych systemów bądź ich zmian - Zamawiający bowiem zaniechał wskazania, że w takim wypadku dostarczy wykonawcy informacje o zaktualizowanych/zmienionych systemach oraz zaniechał zwolnienia odpowiedzialności wykonawcy za brak integracji wynikający z działań lub zaniechań Zamawiającego i firm trzecich.

O wadliwości sformułowania SIWZ świadczy również postanowienie Dodatku 2.3.:

„Wykonanie integracji z urządzeniami oraz systemami, z którymi współpracuje obecnie HIS wraz z odtworzeniem historii przesłań danych: a). Aparat laboratoryjny AQT 90 Radiometer” Zamawiający nakłada na wykonawcę w powyższym punkcie obowiązek integracji przedmiotu zamówienia z posiadanym urządzeniem, jednak w dokumentacji postępowania nie dostarczył informacji dotyczących możliwości integracji z wymienionymi wyżej urządzeniami.

W treści SIWZ brak jest szczegółowych danych technicznych niezbędnych do przeprowadzenia integracji wraz z dokumentacją dotyczącą sposobu komunikacji systemu będącego przedmiotem zamówienia z posiadanym urządzeniem: - dokumentacji opisującej zdolność komunikacji wymienionego urządzenia, z którym ma być przeprowadzona integracja, sposobu komunikacji, opisu transakcji, konstrukcji pliku komunikatu transakcji, pełnej dokumentacji technicznej umożliwiającej integrację; - opisu interfejsów wymiany danych z urządzeń, z którymi ma nastąpić integracja wraz z dokumentacją; - opisu struktury danych w jakich przechowywane są informacje na urządzeniu, z którym ma się integrować dostarczany system.

W związku z powyższym Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ, poprzez:

1. uzupełnienie treści SIWZ o kompletną dokumentacją interfejsów, mechanizmów i opisu protokołów wymiany danych wszystkich systemów oraz urządzeń podlegających integracji, w tym podanie szczegółowych danych technicznych niezbędnych do przeprowadzenia integracji wraz z kompletnymi kodami źródłowymi i dokumentacją dotyczącą sposobu komunikacji tych systemów (zdolność komunikacji, sposób komunikacji, opis transakcji, konstrukcja pliku komunikatu transakcji, pełna dokumentacja techniczna umożliwiająca integrację, opisane widoki baz danych, procedury składowe i inne informacje, które są konieczne do przeprowadzenia integracji) oraz opisu interfejsów wymiany danych wraz z dokumentacją, opisem struktury danych, zakresu danych do wymiany, parametrów dotyczących interfejsów wymiany danych, rodzaju usług i mechanizmów wymiany danych po stronie tych systemów;
2. wprowadzenie w SIWZ i Wzorze umowy zobowiązania Zamawiającego, że w przypadku, gdy podczas wdrożenia lub podczas eksploatacji wdrożonego systemu, w tym na etapie gwarancji, producenci systemów zmienią system lub wersję systemu, zakupią nowe urządzenie lub wymienią obecnie wykorzystywane tak, że będzie to miało wpływ na integrację z oferowanym i wdrożonym systemem, Zamawiający we własnym zakresie i na własny koszt pozyska wszelkie niezbędne do przeprowadzenia ponownej integracji informacje i dane od producenta tych systemów, z którymi miałaby nastąpić ponowna integracja lub poprawa mechanizmów integracyjnych oraz że wykonawca nie będzie ponosił odpowiedzialności ani kosztów za brak integracji wynikający z działań lub zaniechań Zamawiającego i firm trzecich.

ZARZUT II - ZANIECHANIE UDOSTĘPNIENIA INFORMACJI DOT. MIGRACJI Zgodnie z treścią Dodatku 2.3. do SIWZ stanowiącego Opis zakresu czynności w przypadku wymiany sytemu, Zamawiający dopuszcza formalnie możliwość dostarczenia innego rozwiązania informatycznego nakładając na wykonawcę obowiązek zachowania ciągłości pracy organizacji Zamawiającego z uwzględnieniem m.in. migracji danych z obecnie eksploatowanego systemu HIS. Zamawiający wprowadził zapis nakładający na wykonawcę szereg obowiązków w zakresie migracji.

Odwołujący podkreślił, że właścicielem i dysponentem danych zgromadzonych w systemie jest Zamawiający, a nie dostawca obecnie funkcjonującego u Zamawiającego oprogramowania. W treści Dodatku 2.3. nie został wprowadzony zapis, na podstawie którego Zamawiający zapewni wykonawcy dostęp do bazy danych. Z treści przywołanego załącznika wynika, że Zamawiający udostępni wykonawcy opis zawartości poszczególnych tabel.

Wskutek tak sformułowanego brzmienia SIWZ Zamawiający udostępni opis zawartości poszczególnych tabel - w przyszłości - a więc nie na etapie przygotowania oferty. Wykonawcy na etapie złożenia oferty pozbawieni są więc elementarnej wiedzy dotyczącej dokumentacji

struktur baz danych mających podlegać migracji. Postanowienie SIWZ gwarantujące możliwość zapoznania się ze strukturą bazy danych w systemie informatycznym Zamawiającego w ocenie Odwołującego narusza równe traktowanie wykonawców oraz nie pozwala na prawidłowe oszacowanie kosztów związanych z taką migracją.

Poprzez tak sformułowane postanowienia SIWZ, Zamawiający w istocie przerzuca na Wykonawcę obowiązek ustalenia wymagań i warunków technicznych migracji danych.

Odwołujący podtrzymał przywołaną argumentację co do naruszenia zasady uczciwej konkurencji i równego traktowania wykonawców poprzez uprzywilejowanie dostawcy obecnie funkcjonującego u Zamawiającego oprogramowania.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ, poprzez zapewnienie danych do migracji w postaci plików CSV lub XLS zawierających dane do migracji wraz z dokumentacją umożliwiającą pełną identyfikację zawartości tych plików w zakresie koniecznym do migracji danych.

ZARZUT III - MODEL DWUWARTSTWOWY I TRÓJWARSTWOWY W Dodatku 2.2. Wymagane funkcjonalności - Wymagania ogólne - Architektura HIS pkt. 2, Zamawiający sformułował wymagania aby system informatyczny funkcjonował zarówno w technologii trójwarstwowej (webowej), jak i technologii dwuwarstwowej (klient serwer).

Aplikacje dwuwarstwowe są technologiami przestarzałymi, wdrażanymi w latach 90 XX w., wypieranymi przez nowoczesne rozwiązania trójwarstwowe. Rozwiązanie w technologii trójwarstwowej pozwala rozdzielić warstwę prezentacji od logiki biznesowej, dzięki czemu użytkownik (przy użyciu przeglądarki internetowej) ma do czynienia tylko z warstwą prezentacji (widzi aplikację w oknie przeglądarki), podczas kiedy logika biznesowa przeniesiona jest na osobną maszynę. Daje to ogromną przewagę nad architekturą dwuwarstwową, ponieważ do funkcjonowania aplikacji wystarczające jest użycie odpowiedniego adresu w przeglądarce i zalogowanie się bez dodatkowych instalacji i konfiguracji. Administrator opiekuje się wówczas tylko jedną maszyną, która pełni rolę warstwy logiki biznesowej. Rozwiązanie trójwarstwowe jest zdecydowanie lepiej skalowalne - umożliwia obsługę wielu użytkowników, jest wydajne, elastyczne i umożliwia łatwiejsze zarządzanie z punktu widzenia administratora systemu.

Architektura trójwarstwowa jest odpowiedzią na wzrost złożoności programów oraz rozwój sieci komputerowych i znacząco przewyższa architekturę dwuwarstwową.

Odwołujący podkreślił, że praca systemu w architekturze dwuwarstwowej (aplikacja desktop) i jednocześnie trójwarstwowej (aplikacja webowa) nie jest wartością dodaną dla Zamawiającego, a wręcz przeciwnie, jest nieuzasadnioną komplikacją środowiska. Od strony administracyjnej zwielokrotnienie środowisk niesie za sobą zwiększenie nakładu pracy i kosztu ich utrzymania od strony administracyjnej, co wprost prowadzi do wniosku, że narzucanie takiego wymogu w SIWZ nosi cechy niegospodarności i jest rażąco sprzeczne z potrzebami Zamawiającego, jako jednostki sektora finansów publicznych.

Ponadto, Zamawiający wprowadził zapis: „W przypadku niedostępności serwerów aplikacji system musi nadal pracować w wersji dwuwarstwowej”, co jest niezrozumiałe, gdyż w momencie awarii, tj. niedostępności serwerów warstwa serwera jest niedostępna jednakowo dla warstwy przeglądarki, jak i klienta w architekturze dwuwarstwowej.

W ocenie Odwołującego wymaganie dwu- i trójwarstwowej architektury ma na celu ograniczenie konkurencyjności, poprzez faworyzowanie wykonawcy bazującego na przestarzałej technologii, i uniemożliwienie konkurowania w postępowaniu wykonawcom, którzy działają w oparciu o nowoczesne rozwiązania architektury trójwarstwowej. Powyższe, punktowane wymagania nie mają wpływu na przydatność, funkcjonalność oraz jakość oprogramowania dla użytkowników, nie obejmują również obszarów „krytycznych” z punktu widzenia działalności szpitala, np. rozliczeń z NFZ. Wymagania stawiają w uprzywilejowanej pozycji produkt firmy Konsultant IT sp. z o.o.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ poprzez usunięcie z treści Dodatku 2.2. Wymagane funkcjonalności - Wymagania ogólne - Architektura HIS punktu 2.

ZARZUT IV - OBSŁUGA SKRÓTÓW KLAWISZOWYCH Zgodnie z treścią Dodatku 2.2. Wymagane funkcjonalności, Zamawiający wymaga dostarczenia aplikacji działającej zarówno w architekturze trójwarstwowej, jak i w wersji dwuwarstwowej, przy czym zakres używanych skrótów klawiszowych musi być spójny między wersjami architektury systemu. Odwołujący powielił argumentację dotyczącą ograniczenia konkurencyjności - vide zarzut III - i uprzywilejowania produktu firmy Konsultant IT sp. z o.o.

Zdaniem Odwołującego, Zamawiający niezasadnie i niezgodnie ze sztuką, a także w oderwaniu od uzasadnionych potrzeb żąda, aby dostarczone dwie wersje (o różnej architekturze) posiadały tożsamy zakres używanych skrótów klawiszowych. Skróty klawiszowe to klawisze lub kombinacja klawiszy, które zapewniają inny sposób na wykonanie czynności zwykle wykonywanych za pomocą myszy. Zrozumiałym jest dla Odwołującego przywołanie niniejszego wymagania związane ze skróceniem czasu pracy w systemie. Jednak aplikacje desktopowe (o architekturze dwuwarstwowej) wykorzystują skróty klawiszowe, których realizacja jest oparta o kombinację klawiszy modyfikatora (Ctrl, Alt, Shift) z pozostałymi klawiszami dostępnymi w obrębie klawiatury. Z kolei aplikacje webowe (oparte o architekturę trójwarstwową) wykorzystują skróty klawiszowe w oparciu wyłącznie o klawisze dostępne w obrębie klawiatury z wyłączeniem klawiszy modyfikatora. Klawisze te mogą bowiem wpływać na różne akcje w różnych przeglądarkach i różnych systemach, ich eliminacja minimalizuje ryzyko wystąpienia konfliktu z natywną funkcją przeglądarki systemu. Założeniem aplikacji webowych jest dostępność z poziomu różnych przeglądarek i różnych systemów operacyjnych.

Odwołujący wskazał na wymagania zawarte w Dodatku 2.2. Wymagane funkcjonalności - Wymagania ogólne - pkt 29, 30, 31, 32, 33 oraz w Dodatku 7 Scenariusz dotyczący próbki - Funkcje wymagane - pkt 4.

Jako potwierdzenie niezasadności przywołanych powyżej funkcjonalności, Odwołujący wskazał, że interfejs użytkownika nie zawsze musi być związany z konkretną tabelą/kolumną w bazie danych. Funkcjonalność jednoznacznego zlokalizowania pól w bazie danych sugeruje klarownie wykorzystanie konkretnych technologii wykonania interfejsu użytkownika aplikacji i ma na celu jedynie stawianie w uprzywilejowanej pozycji konkretnych wykonawców. Powyżej przywołany argument nie ma wpływu na przydatność, funkcjonalność oraz jakość oprogramowania dla użytkowników. Odwołujący podniósł, że nie sposób zapamiętać wszystkich domyślnych skrótów klawiaturowych w systemie.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ, poprzez:

1. usunięcie pkt 2 z treści Dodatku 2.2. Wymagane funkcjonalności - Wymagania ogólne - Architektura HIS,
2. usunięcie pkt 4 z treści Dodatku 7 Scenariusz dotyczący próbki - Funkcje wymagane.

ZARZUT V - PRZENOSZENIE SESJI Treść Dodatku 7 Funkcje wymagane pkt. 5 wskazuje na wymaganie: „HIS zapewnia możliwość przenoszenia sesji użytkownika z jednego stanowiska komputerowego na drugie.

System wyświetla na ekranie, z którego sesja została przeniesiona, informacje dokąd przeniesiono sesję”. Dodatkowo dla całej funkcjonalności Zamawiający wprowadził Sposób prezentacji wymogu, m.in.: „(...) Następnie należy zaprezentować w pierwszej uruchomionej przeglądarce (sesji) dokąd została przeniesiona.”

Zdaniem Odwołującego, funkcjonalność przenoszenia sesji powinna usprawnić pracę, aby po przejęciu pierwszej sesji móc kontynuować pracę w nowym miejscu, skrócić czas niezbędny do odnalezienia się w nowym środowisku. Informacja o tym, dokąd sesja została przeniesiona nie niesie za sobą żadnych informacji dla osoby, która wyszła z pokoju, w którym się znajdowała, więc jest informacją zbędną. Ponadto, aby prezentować taką informację użytkownik powinien pozostać zalogowanym na jednym urządzeniu (np. w Gabinecie A), następnie, bez wylogowania, pozostawić komputer bez opieki i przejąć sesję na kolejnym (np. w Gabinecie B), co wiąże się ze skrajnym naruszeniem zasad bezpieczeństwa, a w konsekwencji możliwości przejęcia danych szczególnie wrażliwych. Budzi szczególną wątpliwość sytuacja, w której Zamawiający żąda dostarczenia, ponadto już na etapie próbki systemu, funkcjonalności, której scenariusz realizacji niejako wprost łamie założenia bezpiecznego przetwarzania danych, jest niezgodny z przepisami dotyczącymi ochrony danych osobowych i zasadami przetwarzania dokumentacji medycznej. Zapis jest wewnętrznie sprzeczny z wymogiem z § 5 ust. 2 Umowy (Dodatek 5): „Wykonawca ma pełną wiedzę o szczególnym charakterze danych przechowywanych w systemie informatycznym Zamawiającego (m.in. dane osobowe i dane medyczne) i w związku z powyższym w okresie wdrożenia wdroży wszelkie niezbędne środki ostrożności techniczne, informatyczne i

proceduralne wymagane przepisami i najlepszą dostępną praktyką w tym zakresie w celu ochrony tych danych przed ujawnieniem, zniszczeniem lub przypadkową, niezaplanowaną modyfikacją. W szczególności zaprojektowana architektura systemu informatycznego powinna się charakteryzować wysokim stopniem bezpieczeństwa (...)”.

Powyższe zapisy są konsekwencją wymagań stawianych w Dodatku 2.2. - Wymagania ogólne - Aplikacja.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ, poprzez:

1. usunięcie z treści Dodatku 2.2. Wymagane funkcjonalności - Wymagania ogólne Aplikacja zapisów dotyczących wymagania przenoszenia sesji wykraczającego poza zakres podstawowy wymagania, tj. poza możliwość przenoszenia sesji użytkownika z jednego stanowiska komputerowego na drugie.
2. usunięcie pkt 5 z treści Dodatku 7 Scenariusz dotyczący próbki - Funkcje wymagane.

ZARZUT VI - WADLIWIE SPORZĄDZONY SCENARIUSZ PREZENTACJI Ad. a Zgodnie z treścią Dodatku nr 7 do SIWZ, „Dopuszcza się nagrywanie przez Zamawiającego przebiegu demonstracji kamerą video i/lub innymi środkami audiowizualnymi.

Przedstawiciele Wykonawcy nie będą upoważnieni do rejestracji przebiegu demonstracji w postaci audio-video.”

Odwołujący wskazał, że zapis ten jest rażąco asymetryczny i stanowi jaskrawy przykład naruszenia zasady jawności postępowania. Brak jest racjonalnych powodów i potrzeb po stronie Zamawiającego, które uzasadniałyby, dlaczego wykonawca nie może zarejestrować swojej prezentacji (np. jako dowód do KIO w przypadku sporów z Zamawiającym). Oczywistym skutkiem zapisu jest pozbawienie wykonawcy realnej możliwości korzystania z przysługujących mu środków ochrony prawnej w przypadku sporu co do tego, czy dana funkcjonalność jest spełniona. Zapis stanowi jaskrawe nadużycie pozycji Zamawiającego i w żaden sposób nie jest uzasadniony jego potrzebami, a nadto jest oczywiście i rażąco sprzeczny z zasadą jawności postępowania i obowiązkiem dokumentowania czynności przez Zamawiającego.

Ad.b Zgodnie z treścią Dodatku nr 7 do SIWZ: „14. Zamawiający ma prawo żądać zmodyfikowania wartości parametrów, bądź danych wprowadzanych do systemu na wartości podane przez niego, celem sprawdzenia czy demonstrowana funkcjonalność nie jest przez Wykonawcę symulowana. 15. Zamawiający ma prawo zadawać pytania Wykonawcy w zakresie prezentowanych wymogów funkcjonalnych, mające na celu ustalenie czy dana funkcjonalność jest rzeczywiście realizowana.”

Zdaniem Odwołującego, czas, w którym Zamawiający realizuje powyższe uprawnienia w toku prezentacji, nie powinien wchodzić do czasu prezentacji. Wykonawca nie ma żadnego wpływu na to, ile czasu Zamawiający przeznaczy na ww. czynności, brak jest jakichkolwiek podstaw ustawowych, które mogłyby doprowadzić do przeniesienia na wykonawcę ryzyka w tym zakresie. Pozostawienie ww. zapisów bez żadnych obostrzeń, w powiązaniu z brakiem możliwości zarejestrowania dźwięku i obrazu, wprost prowadzi do nierównego traktowania wykonawców, gdyż umożliwia Zamawiającemu zadawanie różnych pytań różnym wykonawcom, żądanie modyfikacji różnych parametrów czy danych, a w konsekwencji narusza zasadę uczciwej konkurencji. Na gruncie Pzp nie jest do zaakceptowania sytuacja, w której ocena próbek poszczególnych wykonawców przebiega każdorazowo w inny sposób.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ, poprzez:

1. wprowadzenie możliwości zarejestrowania dźwięku i obrazu przez wykonawcę przy użyciu kamery wideo przy weryfikacji jego oprogramowania,
2. wprowadzenie zapisu, iż czas na pytania Zamawiającego i odpowiedzi wykonawcy, o których mowa w pkt 15, jak i czas na modyfikacje, o których mowa w pkt 14, nie jest wliczany do czasu prezentacji.

ZARZUT VII - TERMIN REALIZACJI ZAMÓWIENIA Zgodnie z treścią SIWZ, termin wykonania zamówienia wynosi 90 dni od podpisania umowy o udzielenie zamówienia. Zgodnie z treścią Dodatku 2.3. do SIWZ stanowiącego Opis

zakresu czynności w przypadku wymiany sytemu, Zamawiający dopuszcza formalnie możliwość dostarczenia innego rozwiązania informatycznego, w miejsce obecnie funkcjonującego oprogramowania HIS, nakładając na potencjalnego wykonawcę dodatkowo obowiązek zachowania ciągłości pracy organizacji Zamawiającego.

Odwołujący wskazał na postanowienia Dodatku nr 5 do SIWZ zawarte w § 3, § 4 I wskazał, że ww. postanowienia nie są dostosowane do sytuacji, w której wykonawca chciałby wymienić HIS, gdyż nie obejmują wszystkich obowiązków Zamawiającego niezbędnych do realizacji umowy. Choć Zamawiający formalnie dopuszcza wymianę to Zamawiający nie ma żadnego terminu na odniesienie się do zaprezentowanego harmonogramu, a jednocześnie wykonawca jest zobowiązany z nim uzgodnić termin szeregu czynności, które są niezbędne do wykonania po stronie Zamawiającego, tak aby wdrożenie było możliwe. Zamawiający, poprzez rażąco krótki termin wykonania umowy (który nie wynika z jego potrzeb i nie wynika z zasad dofinansowania) de facto blokuje udział w postępowaniu wykonawcom innym niż producent obecnie funkcjonującego w szpitalu oprogramowania, gdyż wykonawca wymieniający HIS ma do zrealizowania dodatkowe obowiązki.

Zamawiający w niespójny sposób uregulował kwestię odbiorów (§ 6 ust. 3, 4, 5, 8, 11).

Z jednej strony ma 14 dni na dokonanie sprawdzenia prac od daty przekazania mu ich do odbioru - z drugiej ma termin 7 dni na wyznaczenie odbioru końcowego od daty zawiadomienia o gotowości do obioru. W odniesieniu do etapów Zamawiający nie jest ograniczony żadnym terminem, w którym miałoby się odbywać testowanie oprogramowania (ust. 3 - 5). Brak precyzyjnego uregulowania powoduje niemożność prawidłowego oszacowania ryzyka, kosztów, a w rezultacie ceny oferty.

Zdaniem Odwołującego, narzucony termin jest nieproporcjonalny i nie wynika z uzasadnionych potrzeb Zamawiającego, a ponadto utrudnia uczciwą konkurencję, gdyż uprzywilejowuje dotychczasowego wykonawcę, który nie musi dokonywać wymiany dotychczasowego oprogramowania.

Biorąc pod uwagę, iż czynności Zamawiającego w ramach realizacji umowy wydają się zajmować co najmniej połowę czasu przeznaczonego na jej realizację, zasadnym jest wydłużenie terminu realizacji umowy o min. 60 dni. W związku z powyższym Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ, poprzez wydłużenie terminu realizacji umowy do 150 dni.

Wykonawca SIMPLE S.A. z siedzibą w Warszawie oraz wykonawca Konsultant IT Sp. z o.o. z siedzibą w Poznaniu zgłosili swoje przystąpienia do postępowania odwoławczego w niniejszej sprawie po stronie Zamawiającego.

Pismem z dnia 14 października 2019 r. Zamawiający złożył odpowiedź na odwołanie.

Wniósł o umorzenia postępowania w części, w której uwzględnił część zarzutów i zmienił treść SIWZ oraz o oddalenie odwołania w pozostałym zakresie, a także o zasądzenie na rzecz Zamawiającego kosztów zastępstwa procesowego.

Głównym celem projektu objętego zamówieniem jest informatyzacja administracji szpitala w Słubicach w celu polepszenia jakości usług dla mieszkańców powiatu słubickiego.

Długofalowym celem projektu jest tworzenie i rozbudowa systemów teleinformatycznych służących upowszechnianiu dostępu do zasobów administracji publicznej. Do celów szczegółowych należą:

1. Zwiększenie liczby e-usług w zakresie komunikacji na linii „szpital - pacjent" i „pacjent - szpital”.
2. Standaryzacja elektronicznej bazy danych, pozwalająca na przyspieszenie agregacji danych i posiadanie aktualnych danych o ilości i jakości świadczeń medycznych.
3. Poprawa stanu infrastruktury ICT Szpitala Powiatowego w Słubicach.
4. Optymalizacja procesów administracyjnych związanych ze świadczeniem usług publicznych, skutkująca zwiększeniem komfortu pacjentów oraz wydajności „szarego" personelu szpitala.
5. Wzrost poziomu kompetencji „szarego” personelu.

Zamawiający wyjaśnił, że przygotowując proces zmian w obsłudze pacjentów i wzrostu jakości świadczonych usług w przygotowanym Studium Wykonalności Projektu: Wdrożenie usług i aplikacji w zakresie e-zdrowia w Szpitalu im. prof. Z. Religi w Słubicach Sp. z o.o. dokonał szczegółowej analizy opcji przedmiotowego przedsięwzięcia. Analizie poddano opcję 1 zdefiniowaną jako wdrożenie e-usług o zupełnie nowy gotowy system występujący na rynku do obsługi szpitali, bez możliwości zaimportowania posiadanych danych, oparty na serwerach stacjonarnych szpitala (implementacja zupełnie nowego rozwiązania, tj. wymiana całego systemu szpitalnego na nowy i doposażenie go w nowe funkcjonalności) oraz opcję 2 zdefiniowaną jako wdrożenia nowych funkcjonalności poprzez ich uzupełnienie w obecnie wykorzystywanym systemie szpitalnym, w którym funkcjonalności umożliwią w sposób automatyczny wygenerowanie dokumentacji elektronicznej, która następnie będzie mogła zostać umieszczona na profilu świadczeniobiorcy w portalu dla niego przystosowanym. W opcji 2 założono wdrożenie usług elektronicznych poprzez zaprojektowanie od podstaw zupełnie nowej, docelowej i zintegrowanej instalacji teleinformatycznej usług. Istotą opcji 2 jest bazowanie na danych obecnie posiadanych, które będą mogły być powtórnie wykorzystane.

Analiza wariantów i wybór spośród wariantów przedstawionych w Studium wariantu optymalnego została przeprowadzona za pomocą analizy wielokryterialnej. Zespół opracowujący Studium wykonalności dokonał analizy ww. wariantów i wybrał spośród nich optymalną opcję. Konsultanci uznali, iż z uwagi na to, że w przypadku przedmiotowej inwestycji nie każdy efekt czy wymóg jest możliwy do przedstawienia w formie ilościowej, a tym bardziej pieniężnej, nie jest możliwe sporządzenie pełnej, ilościowej analizy dostępnych wariantów.

W związku z powyższym, na potrzeby porównania zdefiniowanych wariantów realizacji przedsięwzięcia przeprowadzono analizę wielokryterialną. W celu wyboru właściwego wariantu realizacji inwestycji Zespół opracowujący Studium wykonalności zidentyfikował efekty i koszty społeczne dla każdej z rozważnych opcji celem przeprowadzenia analizy wielokryterialnej.

Na potrzeby przeprowadzenia ww. analizy wykorzystano indywidualne cechy poszczególnych wariantów:

• Korzyści finansowe; - Skrócenie czasu wdrożenia; - Skrócenie czasu szkoleń; - Optymalizacja.

Z przedmiotowej analizy bezspornie wynika, że cele projektu zostaną osiągnięte w większym stopniu w przypadku opcji 2 - wdrożenie e-usług wynikających z analizy potrzeb z wykorzystaniem obecnie posiadanych danych i modułów (szpital posiada wdrożony system finansowo —księgowy Simple i system części „białej” Eskulap).

Zgodnie literą Studium, optymalnym wariantem jest wariant Il, ponieważ odwołuje się do zidentyfikowanych potrzeb Beneficjenta, unika zagrożeń związanych z ryzykiem niepowodzenia lub znacznego opóźnienia realizacji projektu informatycznego, a także zapewnia niezbędne bezpieczeństwo informacji. Podsumowując analizę wariantową przedmiotowej inwestycji, konsultanci uznali, że opcja 2 jest znacząco korzystniejsza z uwagi na postawione przed inwestycją cele i rezultaty.

Tym samym nieprawdziwe są twierdzenia Odwołującego, że jakoby „istnieje duże prawdopodobieństwo, iż całość działań Zamawiającego w toku realizacji projektu finansowanego ze środków unijnych (począwszy od przygotowania dokumentacji projektowej i założeń projektu) ma cechy niegospodarności, a całość projektu jest lapidarnie mówiąc skrojona pod jednego wykonawcę (obecnego dostawcę oprogramowania HIS — czyli Szpitalnego Systemu Informatycznego u Zamawiającego), bez uwzględnienia faktu, iż potrzeby Zamawiającego można zrealizować w sposób konkurencyjny.”

Przedmiot zamówienia, jak i cała dokumentacja została przygotowana w sposób zgodny z obowiązującymi przepisami, w szczególności ustawą Pzp. Zamawiający zaprezentował w niej obecny stan oraz potrzeby i cele, które zamierza zrealizować. Tylko

kompleksowa i dogłębna lektura całości pozwoli na przygotowanie optymalnej oferty. Dla innych wykonawców działających na rynku, w tym dostawców systemów rozmaitych rozwiązań informatycznych, materiały przetargowe nie stanowiły podstawy do złożenia odwołania. Co więcej cześć wykonawców zgłosiła przystąpienia do postępowania odwoławczego po stronie Zamawiającego. Zdaniem Zamawiającego, zaprezentowane przez Odwołującego zarzuty nie znajdują odzwierciedlenia w stanie faktycznym i nie zasługują na uwzględnienie.

Ad. Zarzut I Zarzut dotyczący zaniechania udostepnienia informacji dot. integracji Zamawiający uznał za bezzasadny i niezasługujący na uwzględnienie.

Zamawiający wyjaśnił, że jeżeli dojdzie do wymiany HIS, całkowite koszty tej wymiany pokryje wykonawca. Zamawiający już raz poniósł koszty tych integracji i ponowne wydatki w tym zakresie byłyby naruszeniem dyscypliny finansów publicznych. Zamawiający oczekuje płytkich, podstawowych integracji (zmodyfikował zakresy i doprecyzował protokoły).

Doświadczony wykonawca nie powinien mieć żadnych problemów z przedstawionymi integracjami. Są to typowe integracje w obszarze systemów medycznych, funkcjonujące w większości Szpitali.

Zamawiający zmienił treść SIWZ w zakresie wymaganych integracji. Aktualne wymaganie w SIWZ zostało opublikowane na stronie internetowej. Informacja dostępna na Platformie Zakupowej:https://platformazakupowa.pl. Zamawiający zrezygnował z wymagania o treści: „System ma możliwość integracji z innymi aplikacjami działającymi na stacji klienckiej (np. oprogramowaniem innych producentów) w taki sposób, że wybrany ekran systemu można wywołać z zewnętrznej aplikacji bez konieczności logowania do systemu przez użytkownika (jeżeli użytkownik ma konto w systemie, logowanie odbywa się „w tle")."

W zakresie wymagania: „Umożliwienie przekazywania elektronicznych dokumentów medycznych jak również ich podpisów w ramach integracji z innymi systemami.” Zamawiający wyjaśnił, że chodzi tu o integracje określone przepisami prawa np. z platformą PI lub PZ.

Ad. Zarzut II Zarzut dotyczący zaniechania udostępnienia informacji dot. migracji Zamawiający uznał za bezzasadny i niezasługujący na uwzględnienie.

Zamawiający wyjaśnił, że określił zakres danych do migracji oraz zapewnił dostęp do schematu struktury tabel, jak również dostęp z poziomu administratora do bazy danych.

Zakres danych obejmuje typowe dane ewidencjonowane w systemach medycznych, profesjonalny wykonawca, który ma doświadczenie w wymianie systemów HIS, nie powinien mieć żadnego problemu ze spełnieniem tych oczekiwań. Zamawiający w Dodatku 2.3 wyczerpująco opisał sposób wymiany systemu na inny, mając na względzie zachowanie transparentności oraz zasadę równego traktowania wykonawców. Zamawiający potwierdza, że z wykonawcą wybranym w postępowaniu zawrze umowę powierzenia danych osobowych oraz udzieli dostępu do bazy danych w celu dokonania migracji, zgodnie z wymaganiami Dodatku 2.3.

Ad. Zarzut III Zarzut dotyczący modelu dwuwarstwowego i trójwarstwowego Zamawiający uznał za bezzasadny i niezasługujący na uwzględnienie.

Zamawiający wyjaśnił, że oczekuje całego systemu w nowoczesnej technologii trójwarstwowej, a dodatkowo dla krytycznych dla funkcjonowania szpitala funkcjonalności wymaga równolegle działającej wersji dwuwarstwowej. Mając na uwadze infrastrukturę, którą posiada Zamawiający, argumentem dla podtrzymania ww. wymogu jest bezpieczeństwo i ciągłość funkcjonowania (w rozumieniu dostępu do danych/systemu). Aktualnie szpital ma jeden serwer z bazą danych i do niego łączą się komputery z wersją dwuwarstwową. Gdy nastąpi awaria serwera bazodanowego następuje przestój całości systemu, a tym samym pracy szpitala. Zamawiający dokupuje więc drugi serwer, na którym zostanie zainstalowana aplikacja przeglądarkowa (trójwarstwowa). Tak więc szpital będzie miał kolejny krytyczny serwer, który jeśli ulegnie awarii, to zostanie unieruchomiona całość. W tym miejscu należy wyjaśnić, że awaria może dotyczyć nie tylko fizycznego sprzętu, ale również zewnętrznego oprogramowania zainstalowanego na serwerze aplikacyjnym (system operacyjny, serwer www). Oprogramowanie to również podlega aktualizacjom, które często wymagają przestoju całego rozwiązania. Dlatego w takiej sytuacji przydatna, a właściwie niezbędna będzie wersja dwuwarstwowa, która umożliwi połącznie z bazą z pominięciem serwera aplikacyjnego i

zapewni możliwość dalszego funkcjonowania placówki.

Podsumowując, Zamawiający chce zminimalizować ryzyko przestojów systemu z przyczyn sprzętowych i oprogramowania zewnętrznego zainstalowanego na serwerze aplikacji. Dodatkowo przeglądarka internetowa jest również oprogramowaniem zewnętrznym, aktualizowanym niezależnie od systemu HIS. Istnieje ryzyko, że na skutek aktualizacji przeglądarki będą problemy z użytkowaniem systemu w wersji webowej do czasu dostosowania ze strony producenta HIS.

Ponadto, Zamawiający ma taki system i w przedmiotowym postępowaniu chce go rozbudować. Nie ma merytorycznych powodów, aby rezygnować z istotnych funkcjonalności tylko dlatego, aby Odwołujący mógł złożyć ofertę.

Ad. Zarzut IV Zarzut dotyczący obsługi skrótów klawiszowych Zamawiający uznał za bezzasadny i niezasługujący na uwzględnienie.

Zamawiający oświadczył, że rezygnuje z wymagania zawartego w Dodatku nr 2.2 o treści: „a zakres używanych skrótów klawiszowych musi być spójny między wersjami architektury systemu”. Zamawiający dokonał stosownej zmiany treści SIWZ. Aktualne wymaganie w SIWZ zostało opublikowane na stronie internetowej. Informacja dostępna na Platformie Zakupowej:

Zamawiający podtrzymał pozostałe wymagania dotyczące obsługi skrótów klawiszowych. Wskazał, że Odwołujący podnosi, iż możliwość budowania zapytań SQL bezpośrednio z aplikacji wpływa na bezpieczeństwo przechowywanych danych, jednak nie zauważa rygoru, iż funkcjonalność ta może być dostępna dopiero po uzyskaniu odpowiednich uprawnień. W praktyce jest przeznaczona dla administratorów systemu. Ponadto, Odwołujący wybiórczo zapoznał się ze specyfikacją. W Dodatku 2.2 w rozdziale dotyczącym Wymagań ogólnych w punktach 100-107 Zamawiający wyraźnie określił szczegółowe wymagania związane z rejestracją w logach dostępu do danych. Wymagania te określają, iż każdy dostęp do danych musi być rejestrowany, również taki, który zostanie uzyskany z poziomu aplikacji za pomocą wspomnianych zapytań SQL. Wyraźnie więc widać, że Odwołujący używa argumentu dotyczącego rzekomego zagrożenia bezpieczeństwa danych tylko dlatego, że nie ma określonej funkcjonalności.

Odwołujący podnosi również, iż nie zawsze wyświetlany element jest związany z konkretną tabelą/kolumną w bazie danych. Jest to dość zaskakujące stwierdzenie, gdyż Zamawiający w punkcie 5 Wymagań ogólnych zawarł wymóg: „HIS posiada architekturę modułową i jest zintegrowany pod względem przepływu informacji oraz użyteczności danych.

Wszystkie moduły HIS pracują w oparciu o tą samą strukturę danych w wyniku czego informacja raz wprowadzona do HIS w jakimkolwiek z modułów jest wykorzystywana we wszystkich innych”. Wymaganie to jasno precyzuje, że każda wprowadzana do systemu informacja musi być zapisywana w bazie danych i musi być dostępna dla pozostałych obszarów systemu, więc w praktyce powinna być wprowadzana jednokrotnie. Zamawiający nie dostrzega technicznych problemów z możliwością wyświetlenia „źródła” danych.

Jednocześnie dopuszcza pola, w których łączone są informacje z kilku źródeł danych, dla tego typu pól oczekuje podania informacji o wszystkich źródłach (lokalizacjach rekordów) danych.

Zakwestionowane w zarzucie IV funkcjonalności są istotnym elementem pracy administratora systemu, pozwalają na szybką reakcję w przypadku zgłoszenia problemów z aplikacją bądź z przydzielonymi uprawnieniami. Zdecydowanie skracają czas działań serwisowych. Ponadto, tak przystępna informacja o źródle danych, ułatwia w bardzo dużym stopniu tworzenie zapytań i dodatkowych raportów, gdyż nie wymaga od administratora szczegółowej znajomości struktury bazy danych. Administrator może bez problemu podejrzeć w jakich tabelach i kolumnach znajdują się interesujące go dane i przy znajomości podstaw SQL może w prosty sposób tworzyć wymagane raporty i zestawienia. Dzięki temu w przyszłości koszty eksploatacji systemu będą mniejsze i nie będą wymagały stałego wsparcia ze strony wykonawcy, a jedynie wykwalifikowanego pracownika placówki.

Ad. Zarzut V Zarzut dotyczący przenoszenia sesji Zamawiający uznał za bezzasadny i niezasługujący na uwzględnienie.

Zamawiający podtrzymał wymaganie dotyczące informacji dla użytkownika dokąd została przeniesiona sesja. Zdaniem Zamawiającego, Odwołujący nie przeanalizował

dokładnie specyfikacji i nie zauważył oczekiwanych wymogów dotyczących zabezpieczenia danych. W Wymaganiach ogólnych w punkcie 64 znajduje się informacja, iż system ma mieć obsługę screenlock (blokadę ekranu), czyli użytkownik odchodzący od komputera nie musi kończyć pracy z aplikacją. Wystarczy, że włączy funkcję screenlock i może przejść do innych zadań lub do innego komputera (np. z oddziału na Izbę Przyjęć), gdzie będzie mógł przejąć poprzednią sesję i kontynuować pracę. Po powrocie do pierwszego stanowiska i odblokowaniu screenlock powinien dostać informację dokąd sesja została przeniesiona. Tak zorganizowany system przenoszenia sesji jest bardzo pomocny dla użytkowników, którzy często zmieniają stanowisko pracy np. lekarzy którzy pracują na oddziale, mają konsultacje na Izbie Przyjęć i dodatkowo operują na bloku operacyjnym. Informacja dokąd przeniesiono sesję powoduje lepszą organizację pracy personelu medycznego, co jest również celem postępowania.

Ad. Zarzut VI Zarzut dotyczący wadliwego sporządzenia scenariusza prezentacji Zamawiający uznał za bezzasadny i niezasługujący na uwzględnienie.

W ocenie Zamawiającego, jest to typowy regulamin prezentacji. Zamawiający wyznaczył czas na prezentację próbki na 6 godzin. Podczas szacowania przewidzianego czasu Zamawiający uwzględniał czas potrzebny za zadawanie pytań oraz prośby zmiany parametrów celem potwierdzenia, że prezentowany system nie jest makietą, a próbką działającego systemu. Zamawiający chce uniknąć sytuacji, w której podczas prezentacji nie będzie mógł zweryfikować deklarowanych przez potencjalnego wykonawcę wymagań systemu.

Zamawiający wyjaśnił, że oczekuje gotowego do działania systemu i podczas prezentacji chce zweryfikować jego działanie. Celem Zamawiającego nie jest dokładanie kolejnych punktów prezentacji, ale sprawdzanie funkcji na np. innych danych.

Ad. Zarzut VII Zarzut dotyczący terminu realizacji zamówienia Zamawiający uznał za bezzasadny i niezasługujący na uwzględnienie.

Zamawiający wyjaśnił, że termin ten znajduje bezpośrednie potwierdzenie i wynika z uzasadnionych potrzeb Zamawiającego. Podkreślił, że bardzo istotnym jest konieczność rozliczenia przyznanych środków z UE. Ponadto, obecnie Zamawiający nie spełnia wymogów wynikających z rozporządzeń ministra dotyczących Elektronicznej Dokumentacji Medycznej obowiązujących od stycznia 2019 r., co wymaga niezwłocznych działań. Niezależnie od powyższego, w styczniu 2020 r. wchodzą w życie obligatoryjnie kolejne wymagania w zakresie np. dotyczącym wprowadzenia eRecepty.

Zdaniem Zamawiającego, wskazany termin jest terminem realnym i możliwym do zrealizowania. Odwołujący nie podniósł żadnego merytorycznego uzasadnienia do wydłużenia terminu realizacji o 60 dni. Dodatkowo Zamawiający podniósł, iż ww. termin nie jest uregulowany „sztywną” datą tylko wyrażony w dniach, co powoduje brak presji na wykonawcach ze względu na np. przedłużającą się procedurę przetargową.

Krajowa Izba Odwoławcza, uwzględniając dokumentację postępowania, dokumenty zgromadzone w aktach sprawy i wyjaśnienia złożone na rozprawie przez strony i uczestników postępowania odwoławczego, ustaliła i zważyła, co następuje.

Odwołanie nie zasługuje na uwzględnienie.

Izba stwierdziła, że Odwołujący wykazał posiadanie legitymacji uprawniającej do wniesienia odwołania, stosownie do art. 179 ust. 1 Pzp.

Wykonawcy: SIMPLE S.A. oraz KONSULTANT IT Sp. z o.o. skutecznie przystąpili do postępowania odwoławczego po stronie Zamawiającego, stosownie do wymogów art. 185 ust.

2 i 3 Pzp.

Izba umorzyła postępowanie odwoławcze w zakresie uwzględnionych w części przez Zamawiającego zarzutów nr I i IV, co do których Zamawiający dokonał zmiany treści SIWZ w dniu 14 października 2019 r. Zamawiający uwzględnił zarzut I w zakresie wykreślenia wymagania zawartego w Dodatku 2.2 - Wymagania ogólne, pkt 22 dotyczącego wymogu integracji oferowanego systemu z innymi aplikacjami w taki sposób, że wybrany ekran systemu można wywołać z zewnętrznej aplikacji bez konieczności logowania do systemu przez użytkownika. Zamawiający w zakresie tego zarzutu dokonał również modyfikacji treści Dodatku 2.3, poprzez doprecyzowanie informacji dotyczących wymagania „wykonanie integracji z urządzeniami oraz systemami, z którymi współpracuje obecnie HIS wraz z odtworzeniem historii przesłań danych: lit.a aparat laboratoryjny AQT90 Radiometer”. W zakresie zarzutu IV Zamawiający uwzględnił żądanie Odwołującego zmiany SIWZ, poprzez usunięcie z treści dodatku 2.2 wymagane funkcjonalności wymagania ogólne, architektura HIS pkt 2. Izba wzięła pod uwagę, że żaden z wykonawców, którzy przystąpili do postępowania odwoławczego nie wniósł sprzeciwu wobec uwzględnienia w części tych zarzutów przez Zamawiającego, odpowiednio do brzmienia art. 186 ust. 4 Pzp.

Izba uznała za niezasadny zarzut naruszenia art. 29 ust. 1 i 2 w zw. z art. 7 ust. 1 Pzp, poprzez opisanie przedmiotu zamówienia i sformułowanie treści specyfikacji istotnych warunków zamówienia w sposób niejednoznaczny, niewyczerpujący, bez uwzględnienia wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty, a także w sposób, który mógłby naruszać uczciwą konkurencję.

Zgodnie z art. 29 ust. 1 Pzp, przedmiot zamówienia opisuje się w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględniając wszystkie wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty. Zgodnie z ust. 2 tego artykułu, przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję.

Zamawiający, jako gospodarz postępowania o udzielenie zamówienia publicznego formułuje treść Specyfikacji Istotnych Warunków Zamówienia, w tym opis przedmiotu zamówienia zgodnie z uzasadnionymi w sposób obiektywny własnymi potrzebami, przy czym jest w swych uprawnieniach ograniczony, poprzez związanie podstawowymi zasadami Prawa zamówień publicznych, takimi jak zasada proporcjonalności, uczciwej konkurencji i równego traktowania wykonawców. Jednym z najistotniejszych elementów dokumentacji przetargowej jest opis przedmiotu zamówienia, który musi uwzględniać wszelkie warunki i wymagania Zamawiającego, przy czym zarówno ich treść merytoryczna jak i sposób sformułowania musi uwzględniać potrzeby potencjalnych wykonawców, umożliwiając prawidłowe sporządzenie oferty. Podkreślić równocześnie należy, że Zamawiający nie musi dostosowywać swoich wymagań do sytuacji konkretnego (każdego) w danej branży, co potwierdza jednolite w tym względzie orzecznictwo KIO.

Formułując wymogi co do przedmiotu zamówienia, Zamawiający powinien przestrzegać zasady proporcjonalności, poprzez sformułowanie takich wymagań w zakresie przedmiotu zamówienia, które uzasadnione są specyfiką i charakterem przedmiotu zamówienia, w tym w szczególności jego rozmiarem, złożonością oraz innymi istotnymi warunkami realizacji zamówienia. Zamawiający musi wykazać, że postawione przez niego wymagania są uzasadnione jego obiektywnymi potrzebami.

Na wykonawcy kwestionującym w postepowaniu odwoławczym dane wymagania SIWZ ciąży jednak obowiązek uprawdopodobnienia okoliczności, które wskazuje jako podstawę faktyczną zarzutów. Nie jest wystarczające samo postawienie przez Odwołującego tezy, że określone zasady zostały przez Zamawiającego naruszone.

W tym miejscu należy wskazać, że Odwołujący nie uprawdopodobnił okoliczności, że w przedmiotowym postępowaniu sposób sformułowania dokumentacji przetargowej (w szczególności opisu przedmiotu zamówienia i umowy) sprawia, że jedynym podmiotem, który

jest w stanie zidentyfikować, co w ogóle jest przedmiotem zamówienia i jakie obowiązki będą ciążyły na wykonawcy, którego oferta została wybrana jest obecny dostawca oprogramowania HIS (czyli Szpitalnego Systemu Informatycznego) obecnie funkcjonującego u Zamawiającego.

W pierwszej kolejności należy wskazać na specyfikę działalności Zamawiającego jako placówki świadczącej usługi medyczne, z którą to działalnością jest ściśle powiązany przedmiot zamówienia. Zgodnie z treścią SIWZ, przedmiotem zamówienia jest rozbudowa i wdrożenie usług i aplikacji w zakresie e-zdrowia w Szpitalu im. prof. Z. Religi w Słubicach Sp. z o.o., poprzez wyposażenie jednostki w innowacyjne narzędzia i oprogramowanie informatyczne do świadczenia usług z wykorzystanie nowoczesnych technologii (e-usługi) i zarządzania szpitalem.

Głównym celem projektu jest dokończenie informatyzacji szpitala w Słubicach w celu polepszenia jakości usług dla mieszkańców powiatu słubickiego. Długofalowym celem projektu jest tworzenie i rozbudowa systemów teleinformatycznych służących upowszechnianiu dostępu do zasobów administracji publicznej. Do celów szczegółowych należą zwiększenie liczby e-usług w zakresie komunikacji na linii „pacjent-szpital” i „szpital-pacjent”, standaryzacja elektronicznej bazy danych, pozwalająca na przyspieszenie agregacji danych i posiadanie aktualnych danych o ilości i jakości świadczeń medycznych, poprawa stanu infrastruktury ICT (Information and Communication Technologies) Szpitala, optymalizacja procesów administracyjnych związanych ze świadczeniem usług publicznych, skutkująca zwiększeniem komfortu pacjentów oraz wydajności personelu szpitala, a także wzrost poziomu kompetencji personelu.

Postępowanie powiązane jest ze strategiami: "Lubuska Strategia Ochrony Zdrowia na lata 2014 — 2020” "Program Rozwoju Innowacji", "Strategia Rozwoju Gminy”, "Strategia Rozwoju Polski Zachodniej do roku 2020" "Strategia Rozwoju Powiatu", "Strategia Rozwoju Województwa Lubuskiego 2020",” Strategia UE Morza Bałtyckiego”.

Projekt dofinasowany z Europejskiego Funduszu Rozwoju Regionalnego w ramach Osi Priorytetowej 2 — 5 i 9 Regionalnego Programu Operacyjnego — Lubuskie 2020.

Szczegółowy opis przedmiotu zamówienia przedstawiono w Dodatku nr 2 oraz 2.1 —2.5 do SIWZ.

W pkt 5 SIWZ Zamawiający zastrzegł, iż oferowane rozwiązanie ma być rozwiązaniem działającym, gotowym do wdrożenia i zapewniającym realizację wszystkich wymaganych w SIWZ funkcjonalności. Rozwiązanie nie może być w fazie budowy, testów, projektowania itp.

W pkt 6 SIWZ Zamawiający oświadczył, że umożliwia przeprowadzenie wizji lokalnej przez Wykonawców. Termin wizji przewidziany jest w okresie od ogłoszenia do terminu składania ofert. W celu ustalenia dokładnej daty i godziny wizji wykonawca powinien skontaktować się Zamawiającym za pośrednictwem platformy w sposób opisany w Rozdziale 16. Brak przeprowadzenia wizji lokalnej ze strony Wykonawcy nie może być podstawą do jakichkolwiek roszczeń w stosunku do Zamawiającego podczas realizacji umowy.

W rozdziale 19 SIWZ pkt 5.1 Zamawiający postawił wymaganie, dotyczące próbki oferowanego systemu:

„5.1 Zamawiający żąda złożenia wraz z ofertą próbki, zawierającej wersję demonstracyjną oferowanego oprogramowania. Niedołączenie próbki do oferty będzie skutkowało odrzuceniem oferty. W trakcie oceny ofert Zamawiający dokona badania wersji demonstracyjnej oprogramowania złożonego przez Wykonawcę wraz z ofertą, poprzez przeprowadzenie prezentacji oprogramowania na zasadach określonych w Dodatku nr 7 do SIWZ. Celem przeprowadzenia prezentacji jest dokonanie oceny oferty Wykonawcy czy oferta spełnia wymogi SIWZ. Prezentacja odbędzie się w siedzibie Zamawiającego w terminie wyznaczonym przez Zamawiającego. O terminie prezentacji Próbki będzie decydować kolejność złożonych ofert. O miejscu i terminie przeprowadzenia prezentacji oprogramowania, Wykonawcy zostaną poinformowani odrębnym pismem z co najmniej 5-dniowym wyprzedzeniem terminu prezentacji. Zamawiający nie przewiduje zmiany terminu prezentacji Próbki z przyczyn leżących po stronie Wykonawcy."

Zamawiający wyjaśnił na rozprawie, że przygotowując proces zmian w obsłudze pacjentów i wzrostu jakości świadczonych usług w przygotowanym Studium Wykonalności Projektu: Wdrożenie usług i aplikacji w zakresie e-zdrowia w Szpitalu im. prof. Z. Religi w Słubicach Sp. z o.o. dokonał szczegółowej analizy opcji przedmiotowego przedsięwzięcia.

Wdrożenie e-usług wynika z analizy potrzeb z wykorzystaniem obecnie posiadanych danych i modułów (szpital posiada wdrożony system finansowo —księgowy Simple i system części” białej” Eskulap).

W odniesieniu do szczegółowo sformułowanych zarzutów zawartych w odwołaniu Izba ustaliła i zważyła, jak poniżej:

Zarzut I.

Izba nie stwierdziła zaniechania przez Zamawiającego określenia w SIWZ wszystkich wymaganych danych dotyczących obowiązku dokonania przez wykonawcę integracji z systemami obecnie wykorzystywanymi przez Zamawiającego. Zamawiający umożliwił wykonawcy realizację zamówienia poprzez rozbudowę istniejącego systemu lub dostarczenie nowego rozwiązania, w związku z czym jeżeli dojdzie do wymiany HIS, to całkowity koszt tej wymiany pokryje wykonawca, który wybierze takie rozwiązanie. Zamawiający wyjaśnił, że oczekuje płytkich, podstawowych integracji (zmodyfikował zakresy i doprecyzował protokoły), z którymi doświadczony wykonawca nie powinien mieć żadnych problemów, co potwierdził na rozprawie także Przystępujący. Jak wyjaśnił Zamawiający, są to typowe integracje w obszarze systemów medycznych, funkcjonujące w większości Szpitali. Dodatkowo Przystępujący wyjaśnił, że rozwiązania tego typu są standaryzowane i jako takie dostępne na rynku dla wykonawców.

Uwzględniając fakt, że Zamawiający zmienił treść SIWZ w zakresie wymaganych integracji oraz w świetle przedstawionych wyjaśnień należało przyjąć, że treść SIWZ (Dodatek 2.3) zawiera szczegółowy opis czynności, które ma wykonać wykonawca w ramach wdrożenia systemu. Zamawiający zobowiązał się przy tym udostępnić wykonawcy wszystkie informacje, które posiada, a które będą przydatne do wykonania tych czynności.

Ponadto, jak wynika z treści pkt 5 SIWZ, przedmiotem zamówienia jest gotowy produkt, a zgodnie z pkt 6 wykonawca ma możliwość przeprowadzenia wizji lokalnej w szpitalu, w celu zapoznania się z zasobami Zamawiającego, którymi dysponuje Zamawiający na potrzeby niniejszego zamówienia.

W ocenie Izby, niezasadne jest żądanie Odwołującego wprowadzenia w SIWZ i Wzorze umowy dodatkowego zobowiązania Zamawiającego, że w przypadku gdy podczas wdrożenia lub podczas eksploatacji wdrożonego systemu, w tym na etapie gwarancji, producenci systemów zmienią system lub wersję systemu, zakupią nowe urządzenie lub wymienią obecnie wykorzystywane, tak że będzie to miało wpływ na integrację z oferowanym i wdrożonym systemem - Zamawiający we własnym zakresie i na własny koszt pozyska wszelkie niezbędne do przeprowadzenia ponownej integracji informacje i dane od producenta tych systemów, z którymi miała by nastąpić ponowna integracja lub poprawa mechanizmów integracyjnych oraz że wykonawca nie będzie ponosił odpowiedzialności ani kosztów za brak integracji wynikający z działań lub zaniechań Zamawiającego i firm trzecich. Zdaniem Izby, przedmiot zamówienia, jak i umowa w sprawie zamówienia w danym stanie faktycznym przedstawionych przez Odwołującego hipotetycznych stanów faktycznych nie obejmuje, więc regulacja tych kwestii jest zbędna.

Zarzut II Izba nie stwierdziła zaniechania przez Zamawiającego zaniechania określenia w SIWZ wszystkich wymaganych danych dotyczących obowiązku dokonania przez wykonawcę migracji danych w przypadku podjęcia decyzji o wymianie systemu.

Zamawiający w sposób jednoznaczny określił w Dodatku 2.3 zakres danych do migracji oraz zapewnił dostęp do schematu struktury tabel, jak również dostęp z poziomu administratora do bazy danych. Skoro zakres danych obejmuje typowe dane ewidencjonowane w systemach medycznych, profesjonalny wykonawca, który ma doświadczenie w wymianie systemów HIS, nie powinien oczekiwać, że to Zamawiający pozyska te dane samodzielnie i przekaże wykonawcy w celu wprowadzenia do nowego systemu. Podkreślić należy, że Zamawiający przyjął określony zakres przedmiotu zamówienia, a wykonawca podejmuje decyzję odnośnie możliwości jego wykonania. Zamawiający nie ma obowiązku dostosowywania przedmiotu zamówienia do oczekiwań danego wykonawcy, w szczególności, jeśli Zamawiający jest w stanie uzasadnić konieczność wykonania takich prac przez wykonawcę wobec braku możliwości samodzielnego dokonania migracji danych przez Zamawiającego, który nie jest podmiotem profesjonalnym w tej dziedzinie. Zamawiający potwierdził, że zgodnie z obowiązującymi przepisami w tym zakresie z wykonawcą wybranym w postępowaniu zawrze umowę powierzenia danych osobowych oraz udzieli dostępu do bazy danych w celu dokonania migracji, zgodnie z wymaganiami Dodatku 2.3.

Zarzut III Wymóg dostarczenia oprogramowania pracującego w modelu dwuwarstwowym i trójwarstwowym nie narusza uczciwej konkurencji i równego traktowania wykonawców. W świetle uzasadnienia przedstawionego przez Zamawiającego nie sposób jest przyjąć, że

Zamawiający postawił powyższy wymóg w celu ograniczenia konkurencji. Odwołujący nie uprawdopodobnił tezy zawartej w odwołaniu, że Zamawiający umożliwia złożenie oferty wyłącznie przez wąską grupę podmiotów.

Mając na uwadze wyjaśnienia Zamawiającego w szczególności infrastrukturę, którą posiada Zamawiający, Izba podziela pogląd, że ww. wymóg jest uzasadniony z punktu widzenia zapewnienia bezpieczeństwa i ciągłości funkcjonowania (w rozumieniu dostępu do danych/systemu). Powyższe potwierdza także opinia przedłożona przez Przystępującego na rozprawie - z zakresu informatyki z dnia 14 października 2019 r. opracowaną przez Piotra Wichrania.

Zamawiający posiada aktualnie infrastrukturę z architekturą dwuwarstwową, zatem wykorzystanie jej w ramach dodatkowego zabezpieczenia prawidłowego funkcjonowania jest uzasadnione z punktu widzenia zarówno ekonomicznego jak i funkcjonalnego. Skoro w ten sposób Zamawiający może zminimalizować ryzyko przestojów systemu z przyczyn sprzętowych i oprogramowania zewnętrznego zainstalowanego na serwerze aplikacji, to należy uznać, że uzasadnienie do pozostawienia systemu w modelu dwuwarstwowym jest w sposób obiektywny uzasadnione.

Dodatkowo należy zauważyć, że model trójwarstwowy systemu Zamawiający traktuje jak podstawowy, a model dwuwarstwowy - jako dodatkowe zabezpieczenie dostępu do danych, w szczególności, aby w trakcie niemożliwości korzystania z systemu trójwarstwowego dostęp do danych był możliwy poprzez system dwuwarstwowy.

Fakt, że w innych postępowaniach zamawiane są systemy o strukturze trójwarstwowej nie ma wpływu na sposób określenia przez Zamawiającego zakresu przedmiotu zamówienia w przedmiotowym postępowaniu, w szczególności ze względu na uzasadnione potrzeby wyjaśnione szczegółowo przez Zamawiającego.

Zarzut IV Zamawiający w części uwzględnił ten zarzut, wykreślając z treści SIWZ postanowienie zakwestionowane przez Odwołującego dotyczące wymogu obsługi skrótów klawiaturowych, iż zakres używanych skrótów klawiszowych musi być spójny między wersjami architektury systemu - dwuwarstwowej i trójwarstwowej. Zamawiający oświadczył, że rezygnuje z wymagania zawartego w Dodatku nr 2.2 o treści: „a zakres używanych skrótów klawiszowych musi być spójny między wersjami architektury systemu”. Zamawiający dokonał stosownej zmiany treści SIWZ. Izba nie podzieliła argumentacji Odwołującego, iż wobec dokonania przez Zamawiającego modyfikacji SIWZ, poprzez wykreślenie pkt 2, który dotyczył skrótów klawiszowych, powinien on również zmienić wymaganie zawarte w pkt 4 (tabeli nr 1) Dodatku nr 7 odpowiednio, choćby poprzez dodanie treści wskazującej na wprowadzenie nowych zapisów. Izba nie stwierdziła sprzeczności treści tych postanowień po dokonanych zmianach.

Zarzut V W świetle wyjaśnień przedstawionych przez Zamawiającego wymóg przenoszenia sesji, rozumiany w ten sposób, iż system wyświetla na ekranie, z którego sesja została przeniesiona, informację dokąd przeniesiono sesję, jest w pełni uzasadniony specyfiką działalności prowadzonej przez Zamawiającego, w szczególności potrzebą wykonywania przez pracowników czynności w różnych miejscach szpitala w ciągu tego samego dnia pracy.

Konieczne przy tym jest, aby dany pracownik mógł uzyskać informację, w których miejscach jego pracy pozostały niezamknięte sesje. Ponieważ nie ma możliwości podglądu tej informacji bez zalogowania, zatem informacja ta nie będzie dostępna dla osób trzecich, na co wskazywał Odwołujący.

Jak wyjaśnił, Zamawiający, a Odwołujący temu nie zaprzeczył, w Wymaganiach ogólnych w punkcie 64 znajduje się informacja, iż system ma mieć obsługę screenlock (blokadę ekranu), czyli użytkownik odchodzący od komputera nie musi kończyć pracy z aplikacją, a wystarczy, że włączy funkcję screenlock i może przejść do innych zadań lub do innego komputera (np. z oddziału na Izbę Przyjęć), gdzie będzie mógł przejąć poprzednią sesję i kontynuować pracę. Po powrocie do pierwszego stanowiska i odblokowaniu screenlock, powinien dostać informację dokąd sesja została przeniesiona. Tak zorganizowany system przenoszenia sesji jest bardzo pomocny dla użytkowników, którzy często zmieniają stanowisko pracy np. lekarzy którzy pracują na oddziale, mają konsultacje na Izbie Przyjęć i dodatkowo operują na bloku operacyjnym. Informacja dokąd przeniesiono sesję powoduje lepszą organizację pracy personelu medycznego, co jest również celem postępowania.

Odwołujący nie uprawdopodobnił również tezy, że opis przedmiotu zamówienia w powyższym zakresie ogranicza uczciwą konkurencję i zasadę równego traktowania wykonawców, w szczególności - że umożliwia złożenie oferty wyłącznie wąskiej grupie wykonawców. Odwołujący nie przedstawił jakiegokolwiek uzasadnienia na te okoliczność.

Zarzut VI W świetle ustalonych okoliczności sprawy nie ma podstaw twierdzenie Odwołującego, że Zamawiający w sposób wadliwy sporządził Scenariusz dotyczący próbki.

Zgodnie z dodatkiem 7 do SIWZ, pkt 8 i 9, Zamawiający wskazał protokół, jako podstawowy dokument rejestrujący przebieg prezentacji z możliwością zgłaszania wszelkich uwag przez wykonawcę. Zamawiający dopuścił także możliwość nagrywania dla zapewnienia zachowania zasady równego traktowania wykonawców w postępowaniu.

Po pierwsze, należy wskazać, że Zamawiający ma prawo dopuścić możliwość nagrywania prezentacji próbki systemu przez wykonawców (Dodatek 7 do SIWZ pkt 9), jako dodatkowy sposób rejestracji przebiegu danej czynności w postępowaniu, jednak nie ma takiego obowiązku. Podkreślić należy, że podstawową zasadą w postępowaniu o udzielenie zamówienia publicznego jest zasada pisemności, czego wyrazem jest obowiązek prowadzenia przez Zamawiającego protokołu postępowania i pisemnego potwierdzenia wykonywanych w postepowaniu czynności. W ocenie Izby, wyłącznie prawem Zamawiającego jest to, czy dopuści możliwość rejestracji prezentacji próbki przez wykonawcę, przy czym odmowa nie zagraża zasadzie jawności postępowania. Podkreślić należy, że dokumentację postępowania stanowią dokumenty (materiały) wygenerowane i prowadzone przez Zamawiającego, jako gospodarza postępowania i te dokumenty stanowią dokumentację postępowania w rozumieniu ustawy Prawo zamówień publicznych. Zatem odmowa wyrażenia zgody przez Zamawiającego na nagrywanie prezentacji przez wykonawcę nie stanowi naruszenia zasady jawności postępowania (art. 8 Pzp).

Po drugie, Zamawiający ma prawo żądać w trakcie prezentacji próbki systemu zmodyfikowania przez wykonawcę wartości parametrów bądź danych wprowadzanych do systemu na wartości podane przez niego, celem sprawdzenia czy demonstrowana funkcjonalność nie jest przez wykonawcę symulowana oraz ma prawo zadawać pytania wykonawcy w zakresie prezentowanych wymogów funkcjonalnych, w celu ustalenia, czy dana funkcjonalność jest rzeczywiście realizowana (Dodatek do SIWZ pkt 14 i 15). Jak wyjaśnił Zamawiający na rozprawie całość prezentacji próbki systemu przewidziana jest na 6 godzin, z czego realizacja scenariusza prezentacji przewidziana jest na 4 godziny, natomiast 2 dodatkowe godziny zostały przewidziane jako czas na pytania Zamawiającego i stosowne czynności i/lub wyjaśnienia wykonawcy.

Zamawiający nie naruszył przepisu § 13 pkt 1 rozporządzenia Ministra Rozwoju z dnia 26 lipca 2016 r. w sprawie rodzajów dokumentów, jakich może żądać zamawiający od wykonawcy w postępowaniu o udzielenie zamówienia (Dz. U. nr 1126 z 2016 ze zm.). Zgodnie z treścią § 13 pkt 1 ww. rozporządzenia, w celu potwierdzenia, że oferowane roboty budowlane, dostawy lub usługi odpowiadają wymaganiom określonym przez zamawiającego, zamawiający może żądać w szczególności: próbek, opisów, fotografii, planów, projektów, rysunków, modeli, wzorów, programów komputerowych oraz innych podobnych materiałów, których autentyczność musi zostać poświadczona przez wykonawcę na żądanie zamawiającego. Mając na uwadze ten przepis, Zamawiający zażądał w niniejszym postępowaniu przedłożenia przez wykonawców próbek systemu, co jest w pełni zgodne z dyspozycją tego przepisu.

Zarzut VII W ocenie Izby, Odwołujący nie wykazał, że 90-dniowy termin przewidziany na realizację umowy jest zbyt krótki dla możliwości prawidłowego wykonania przedmiotu zamówienia. Termin ten jest uzasadniony potrzebami Zamawiającego, który obecnie nie spełnia wymogów wynikających z rozporządzeń dotyczących Elektronicznej Dokumentacji Medycznej obowiązujących od stycznia 2019 r. co wymaga niezwłocznych działań, a niezależnie od powyższego, musi sprostać wymaganiom przepisów, które wchodzą w życie w styczniu 2020 r w zakresie np. dotyczącym wprowadzenia eRecepty.

Nie ma też podstaw by uznać, że termin ten ogranicza uczciwą konkurencję i zasadę równego traktowania wykonawców. Odwołujący nie wykazał - nie uprawdopodobnił w ramach postępowania odwoławczego okoliczności, że tylko wąska grupa wykonawców może złożyć ofertę gdyż termin realizacji umowy został określony przez Zamawiającego w sposób jak wyżej. Ponadto, Odwołujący w żaden sposób nie uzasadnił żądania wydłużenia powyższego terminu o 60 dni. Zamawiający w żaden sposób nie naruszył art. 36 ust. 1 pkt 4 Pzp, który zobowiązuje Zamawiającego do zawarcia w treści SIWZ terminu wykonania zamówienia.

Biorąc pod uwagę stan rzeczy ustalony w toku postępowania, Izba orzekła, jak w sentencji, na podstawie art. 192 ust. 1 Pzp.

O kosztach postępowania odwoławczego orzeczono na podstawie art. 192 ust. 9 i 10 ustawy Pzp oraz § 3 pkt 1 i 2 oraz § 5 ust. 2 pkt 1 rozporządzenia Prezesa Rady Ministrów z dnia 15 marca 2010 roku 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 (t.j. Dz. U. z 2018 r., poz. 972).

29