KIO 1951/19 WYROK dnia 17 października 2019 r.

Sygn. akt: KIO 1951/19 

WYROK 

z dnia 

17 października 2019 r.  

Krajowa  Izba Odwoławcza  -   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: 

umarza postępowanie w zakresie uwzględnionych w części zarzutów I i IV; 

2.  oddala 

odwołanie w pozostałym zakresie, 

kosztami postępowania obciąża wykonawcę: Comarch Healthcare S.A. Al. Jana 

Pawła II 39a, 31-864 Kraków, i: 

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, 

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:   

zaniechanie  określenia  w  SIWZ  wszystkich  wymaganych  danych  dotyczących 

obowiązku  dokonania  przez  wykonawcę  integracji  z  systemami  obecnie wykorzystywanymi 

przez Zamawiającego,  

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,  

żą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,  

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,  

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,  

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,  

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:  

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;   

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:  

usunięcie pkt 2  z treści Dodatku 2.2. Wymagane funkcjonalności – Wymagania ogólne 

– Architektura HIS,  

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:  

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.   

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:  

wprowadzenie  możliwości  zarejestrowania  dźwięku  i  obrazu  przez  wykonawcę  przy 

użyciu kamery wideo przy weryfikacji jego oprogramowania,  

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żą: 

Zwiększenie liczby e-usług w zakresie komunikacji na linii „szpital - pacjent" i „pacjent 

szpital”. 

Standaryzacja elektronicznej bazy danych, pozwalająca na przyspieszenie agregacji 

danych i posiadanie aktualnych danych o ilości i jakości świadczeń medycznych. 

Poprawa stanu infr

astruktury ICT Szpitala Powiatowego w Słubicach. 

Optymalizacja  procesów  administracyjnych  związanych  ze  świadczeniem  usług 

publicznych,  skutkująca  zwiększeniem  komfortu  pacjentów  oraz  wydajności  „szarego" 

personelu szpitala. 

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 

) 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).  

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