rodzaj: WYROK
data dokumentu: 2019-10-17
rok: 2019

sygnatury akt.:

KIO 1951/19

Komisja w składzie:
Przewodniczący: Jolanta Markowska Protokolant: Rafał Komoń

po rozpoznaniu na rozprawie w dniu
15 października 2019 r. w Warszawie odwołania
wniesionego do Prezesa Krajowej Izby Odwoławczej w dniu 30 września 2019 r. przez
wykonawcę: Comarch Healthcare S.A. Al. Jana Pawła II 39a, 31-864 Kraków
w postępowaniu prowadzonym przez zamawiającego: Niepubliczny Zakład Opieki
Zdrowotnej Szpital im. profesora Zbigniewa Religi w Słubicach Sp. z o.o.,
ul. Nadodrzańska 6, 69-100 Słubice,

przy udziale wykonawcy: SIMPLE S.A.,
ul. Bronisława Czecha 49/51, 04-555 Warszawa
zgłaszającego przystąpienie do postępowania odwoławczego po stronie zamawiającego,
przy udziale wykonawcy: Konsultant IT Sp. z o.o., uI. Romana Maya 1, 61-
371 Poznań
zgłaszającego przystąpienie do postępowania odwoławczego po stronie zamawiającego,

orzeka:

1.
umarza postępowanie w zakresie uwzględnionych w części zarzutów I i IV;
2. oddala
odwołanie w pozostałym zakresie,

3.
kosztami postępowania obciąża wykonawcę: Comarch Healthcare S.A. Al. Jana
Pawła II 39a, 31-864 Kraków, i:

1)
zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr
(słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawcę:
Comarch Healthcare S.A.
Al. Jana Pawła II 39a, 31-864 Kraków

tytułem wpisu
od odwołania,

2)
zasądza kwotę 3 600 zł 00 gr (słownie: trzy tysiące sześćset złotych zero groszy)
od wykonawcy: Comarch Healthcare S.A.
Al. Jana Pawła II 39a, 31-864 Kraków

na rzecz zamawiającego:

Niepubliczny Zakład Opieki Zdrowotnej Szpital im.
profesora Zbigniewa Religi w Słubicach Sp. z o.o., ul. Nadodrzańska 6, 69-100
Słubice,

stanowiącą koszty poniesione z tytułu wynagrodzenia pełnomocnika.

Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. -
Prawo zamówień publicznych
(tj. Dz. U. z 2019 r., poz. 1843) na niniejszy wyrok -
w terminie 7 dni od dnia jego doręczenia -
przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu
Okręgowego w Gorzowie Wielkopolskim.

………………………………



Sygn. akt: KIO 1951/19
Uzasadnienie
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
z
amieszczona 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.
1843) 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:
1)
zaniechanie określenia w SIWZ wszystkich wymaganych danych dotyczących
obowiązku dokonania przez wykonawcę integracji z systemami obecnie wykorzystywanymi
przez Zamawiającego,
2)
zaniecha
nie określenia w SIWZ wszystkich wymaganych danych dotyczących
obowiązku dokonania przez wykonawcę migracji danych w przypadku podjęcia decyzji o
wymianie systemu,
3)
żą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,
4)
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 uza
sadnienia dla takiego żądania,

5)
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,
6)
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ć
zmo
dyfikowania wartości parametrów bądź danych wprowadzanych do systemu na wartości
podane przez niego, celem sprawdzenia czy demonstrowana
funkcjonalność nie jest przez
w
ykonawcę 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
r
ozporządzenia w sprawie rodzajów dokumentów, jakich może żądać zamawiający od
w
ykonawcy w postępowaniu o udzielenie zamówienia,
7)
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,
p
osiadają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 r
ealizacji. 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 funk
cjonują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
inneg
o 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 sy
stemami, 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 ni
niejszego 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 w
ykonawca 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 w
ykonawca 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
w
ykonawcó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.
w
prowadzenie 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
me
chanizmó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 do
stę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
funkcjona
lności – Wymagania ogólne – pkt 29, 30, 31, 32, 33 oraz w Dodatku 7 Scenariusz
dotyczący próbki – Funkcje wymagane – pkt 4.
J
ako 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 t
reś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 w
ykonawcy 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 funkcjonal
ność 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
w
ykonawca 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.

Z
amawiają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 Z
amawiają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 1
4 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 infr
astruktury 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 Z
espół 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
wy
korzystaniem 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 w
ykonawcó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 w
ykonawca. 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: https://platformazakupowa.pl
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 i
nnych”. 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 proble
mó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.
Zakwestion
owane 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,
t
ak 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
w
ykonawcach ze względu na np. przedłużającą się procedurę przetargową.


Krajowa Izba Od
woł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 h
istorii 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 I
nformatycznego) 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
p
rzeprowadzenie 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
wyprzedzenie
m 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.
W
droż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
potwierdz
ił, ż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.
Z
amawiają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 pos
tę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, ab
y 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
aplik
acją, 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ą
organiza
cję 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.
Z
godnie 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 wyko
nawcę. 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 c
zynnoś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
w
ykonawcy 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
n
iezależ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).

………………………………

Wcześniejsze orzeczenia:

• Sygn. akt KIO 1833/19, KIO 1875/19 z dnia 2019-10-31
• Sygn. akt KIO 2089/19 z dnia 2019-10-29
• Sygn. akt KIO 1894/19 z dnia 2019-10-24
• Sygn. akt KIO 1948/19 z dnia 2019-10-22
• Sygn. akt KIO 1880/19, KIO 1895/19 z dnia 2019-10-21