NIP: 1132866688 REGON: 012298823

SPECYFIKACJA

ISTOTNYCH WARUNKÓW ZAMÓWIENIA

dla zamówienia publicznego dokonywanego

w trybie przetargu nieograniczonego

na dostawę i wdrożenie systemu informatycznego e-Usługi wraz z modernizacją lub

wymianą zintegrowanego systemu zarządzania (HIS + ERP), systemów

powiązanych i sprzętu

ZP/11/HIS+ERP/2020/UE

w ramach projektu współfinansowanego z funduszy europejskich w ramach

Regionalnego Programu Operacyjnego Województwa Mazowieckiego

na lata 2014-2020 (RPO WM 2014-2020)

„Rozwój e-usług poprzez rozbudowę systemu informatycznego

w Szpitalu Praskim p.w. Przemienienia Pańskiego Sp. z o.o. w Warszawie”

Termin składania ofert: 22.04.2020 r. ,godz. 10:00

Termin otwarcia ofert: 22.04.2020 r. ,godz. 10:30

Podstawa prawa:

Ustawa z dnia 29 stycznia 2004 r. – Prawo zamówień publicznych – tekst jednolity (Dz. U. 2019 r. poz. 1843), zwana

dalej „ustawą” oraz zgodnie z wydanymi na jej podstawie rozporządzeniami wykonawczymi.

Postępowanie o udzielenie zamówienia publicznego prowadzone jest w trybie przetargu nieograniczonego (art. 39

ustawy) o wartości zamówienia większej od kwoty określonej w przepisach wydanych na podstawie art. 11 ust.8.

Strona 2 z 204

1 INFORMACJE O ZAMAWIAJĄCYM.

SZPITAL PRASKI P.W. PRZEMIENIENIA PAŃSKIEGO SPÓŁKA Z OGRANICZONĄ

ODPOWIEDZIALNOŚCIĄ

Aleja Solidarności 67, 03-401 Warszawa

nr tel.: 22 818 50 61 (centrala), 22 555 11 54 (Dział Zamówień Publicznych)

e-mail: zamowienia@szpitalpraski.pl

adres strony internetowej Zamawiającego: www.szpitalpraski.pl

2 TRYB UDZIELENIA ZAMÓWIENIA.

1. Postępowanie o udzielenia zamówienia publicznego prowadzone jest w trybie przetargu

nieograniczonego, o wartości przekraczającej kwoty określone w przepisach wydanych na podstawie

art. 11 ust.8Ustawy z dnia 29 stycznia 2004 roku Prawo zamówień publicznych (Dz. U. 2018 r. poz. 1986),

zwaną dalej „ustawą Pzp”.

2. W zakresie nieuregulowanym w niniejszej Specyfikacji Istotnych Warunków Zamówienia, zwanej dalej

„SIWZ”, mają zastosowanie przepisy ustawy Pzp i wydanych do niej aktów wykonawczych.

3 SŁOWNIK POJĘĆ

Na potrzeby SIWZ, jak i we wszystkich związanych z nią dokumentach nadaje się wymienionym

niżej pojęciom następujące znaczenia:

OPZ – ogólnie opis przedmiotu zamówienia przedstawiony w tym dokumencie.

SIWZ – specyfikacja istotnych warunków zamówienia przedstawiona w tym dokumencie.

Szpital, Zamawiający – Szpitalu Praskim p.w. Przemienienia Pańskiego Sp. z o.o. w Warszawie.

Oferent, Wykonawca – podmiot składający ofertę w postępowaniu przetargowym opisanym w niniejszym

dokumencie.

Użytkownik - oznacza osobę należącą do personelu Zamawiającego, posiadającą uprawnienia do

korzystania wdrażanego Oprogramowania Aplikacyjnego.

Stacja Robocza - Oznacza komputery klasy PC lub/i terminal z monitorem używany przez Użytkownika, na

którym będzie użytkowane wdrażane Oprogramowanie Aplikacyjne ERP.

Oprogramowanie, Aplikacja, Zintegrowany System Informatyczny, ZSI - zbiór współdziałających

i współpracujących ze sobą aplikacji, opisanych w niniejszym dokumencie, wykonujący swoje procedury

we wzajemnej interakcji, realizujący procesy biznesowe Szpitala, będący utworem o właściwościach

w rozumieniu ustawy z dnia 4 lutego 1994 r. „o prawie autorskim i prawach pokrewnych” [tj. Dz.U. 2006

nr 90 poz. 631 ze zm.], do którego prawa autorskie i majątkowe przysługują producentowi (autorowi)

lub Wykonawcy, będący przedmiotem Projektu Wdrożeniowego, który zostanie zrealizowany w wyniku

niniejszego postępowania.

Strona 3 z 204

Moduł Oprogramowania - część składowa ZSI, charakteryzująca się spójnym zakresem merytorycznym

realizowanych funkcji i procesów, wykonująca swoje procedury we wzajemnej interakcji z innymi

aplikacjami wchodzącymi w skład Oprogramowania Aplikacyjnego. Moduł nie jest zdolny w tym

rozumieniu do samodzielnego działania w oderwaniu od innych aplikacji Oprogramowania Aplikacyjnego.

Aplikacja - część składowa ZSI, charakteryzująca się spójnym zakresem merytorycznym realizowanych

funkcji i procesów, wykonująca swoje procedury we wzajemnej interakcji z innymi aplikacjami

wchodzącymi w skład Oprogramowania i zdolna do samodzielnego działania w oderwaniu od innych

aplikacji ZSI.

Rozwiązanie Business Intelligence, BI - System Informowania Kierownictwa klasy business intelligence

(BI) oparty o wielowymiarową bazę danych typu OLAP wraz z warstwą prezentacji raportów i analiz.

Hospital Information System, HIS - część ZSI wspomagająca funkcjonowanie i zarządzanie Szpitalem

w zakresie obsługi pacjenta, zarządzania ruchem chorych, obsługi procedur medycznych i procesów leczenia

pacjentów, zwana też „częścią białą” ZSI.

Picture Archiving and Communication System, PACS - system informatyczny wspomagający

gromadzenie, udostępnianie i wymianę obrazów medycznych.

Radiology Information System, RIS - System informatyczny wspomagający przechowywanie,

przetwarzanie i udostępnianie radiologicznych obrazów medycznych.

Laboratory Information System, LIS - System informatyczny wspomagający gromadzenie,

przechowywanie i przetwarzanie danych medycznych wytwarzanych przez laboratorium diagnostyki

medycznej oraz zarządzanie laboratorium.

Oprogramowanie bazodanowe (motor bazy danych) - oprogramowanie umożliwiające gromadzenie,

przechowywanie i udostępnianie zorganizowanych danych, najczęściej motor bazy danych typu SQL.

Oprogramowanie systemowe (system operacyjny) - oprogramowanie zarządzające systemem

komputerowym, tworzące środowisko do uruchamiania i kontroli zadań użytkownika lub udostępniania

usług w sieci (serwerowy system operacyjny). Serwerowy System Operacyjny jest niezbędny do

prawidłowego funkcjonowania Oprogramowania Bazodanowego i ZSI.

Usługi Wdrożeniowe - oznacza wszelkie świadczenia Oferenta opisane w dokumentach SIWZ, OPZ

oraz wzorze umowy realizowane w celu wdrożenia i uruchomienia Oprogramowania w przedsiębiorstwie

Zamawiającego.

Projekt - zorganizowane przedsięwzięcie realizowane przez Zamawiającego zmierzające do

uruchomienia w jego przedsiębiorstwie Oprogramowania składające się z Usług Wdrożeniowych

realizowanych przez Wykonawcę oraz prac wykonywanych przez Zamawiającego, zgodnie z przyjętą

metodyką wdrożeniową.

Serwer/serwery - system komputerowy dysponujący zasobami umożliwiającymi zainstalowanie

i eksploatację Oprogramowania Bazodanowego i Oprogramowania Aplikacyjnego, udostępniony(-e)

Wykonawcy przez Zamawiającego, przeznaczony(-e) do gromadzenia i przetwarzania danych.

Strona 4 z 204

4 OPIS PRZEDMIOTU ZAMÓWIENIA.

1. Numer referencyjny postępowania: ZP/11/HIS+ERP/2020/UE.

2. Opis przedmiotu zamówienia:

1) przedmiotem zamówienia jest dostawa i wdrożenie systemu informatycznego e-Usługi wraz z

modernizacją lub wymianą zintegrowanego systemu zarządzania (HIS + ERP), systemów

powiązanych i sprzętu na rzecz Szpitala Praskiego p.w. Przemienienia Pańskiego Sp. z o.o.

w Warszawie, którego sposób realizacji został szczegółowo opisany w Załącznikach nr 1-3 do SIWZ

oraz Rozdziale SIWZ - Założenia początkowe oraz wymagania ogólne,Rozdziale SIWZ - Dostawa

i wdrożenie szpitalnego systemu informatycznego, Rozdziale SIWZ - Szczegółowy opis przedmiotu

zamówienia.

3. Nazwa i kod według Wspólnego Słownika Zamówień (CPV).

Zgodnie nomenklaturą CPV na przedmiot zamówienia składają się:

Główny kod CPV:

48000000-8 Pakiety oprogramowania i systemy informatyczne

Uzupełniające kody CPV:

48600000-4 Pakiety oprogramowania dla baz danych i operacyjne,

72000000-5 Usługi informatyczne: konsultacyjne, opracowywania oprogramowania, internetowe

i wsparcia,

80500000-9 Usługi szkoleniowe,

72253200-5 Usługi w zakresie wsparcia systemu.

4. Zamawiający nie dopuszcza składania ofert częściowych

5. Zamawiający nie dopuszcza składania ofert wariantowych

6. Zamawiający nie przewiduje zastosowania aukcji elektronicznej przy wyborze oferty najkorzystniejszej.

7. Zamawiający zastrzega możliwość udzielenia dotychczasowemu wykonawcy dostawzamówienia na

dodatkowe dostawy zgodnie z art. 67 ust. 1 pkt. 7 ustawyPzp. Warunki, na jakich zostaną udzielone

wyżej wymienione zamówienia:

1) zamówienie będzie mogło być udzielone w przypadku, gdy Zamawiający będziedysponował

środkami finansowymi na jego realizację;

2) umowa zostanie zawarta po przeprowadzeniu negocjacji z Wykonawcą;

3) termin wykonania zamówienia będzie proporcjonalny do zakresu zamówienia;

4) wzór umowy zostanie przekazany Wykonawcy wraz z zaproszeniem do negocjacji;

5) kary umowne będą przewidziane w takich samych wypadkach i w wysokości niewyższej jak

w umowie zawartej w postępowaniu na zamówienie podstawowe;

6) obowiązki Wykonawcy i Zamawiającego będąuregulowane na zasadach analogicznychdo umowy

zawartej w wyniku rozstrzygnięcia zamówienia podstawowego.

8. Zamawiający przewiduje możliwośćudzielenia zamówień, o których mowa w art. 67ust. 1 pkt. 7 ustawy

w wysokości do 30 % wartości zamówienia podstawowego.

9. Jeżeli w opisie przedmiotu zamówienia wskazano jakikolwiek znak towarowy, patentczy pochodzenie –

należy przyjąć, że wskazane patenty, znaki towarowe, pochodzenie określają parametry techniczne,

eksploatacyjne, użytkowe, co oznacza, że Zamawiający dopuszcza złożenie oferty w tej części

Strona 5 z 204

przedmiotu zamówienia o równoważnych parametrach technicznych, eksploatacyjnych i użytkowych.

Jednocześnie przypominamy, że zgodnie z art. ust. 5 ustawy Wykonawca, który powołuje się na

rozwiązania równoważne, jest obowiązany wykazać, że oferowany przez niego przedmiot zamówienia

spełnia wymagania określone przez Zamawiającego. Zamawiający wskazuje również, że użył w

niniejszej treści SIWZ znaków towarowych i wskazał pochodzenie w celu opisu posiadanego środowiska

informatycznego i jego komponentów.

10. Zamawiający nie przewiduje zwrotu kosztów postępowania.

11. Zamawiającyżąda od Wykonawcy wskazania w Formularzu ofertowym, jaką część zamówienia powierzy

do realizacji podwykonawcom oraz podania przez Wykonawcę nazw firm podwykonawców. W

przypadku pozostawienia tej części formularza ofertowego bez wypełnienia Zamawiający uzna, że

Wykonawca wykona zamówienie samodzielnie, chyba że z dokumentacji załączonej do oferty będzie

wynikało co innego. Wykonawca, którego oferta zostanie wybrana jako najkorzystniejsza zobowiązany

będzie podać przed przystąpieniem do wykonania zamówienia, nazwy albo imiona i nazwiska oraz dane

kontaktowe podwykonawców i osób do kontaktu z nimi, o ile będą już znane. Wykonawca zobowiązany

będzie także do powiadamiania Zamawiającego o wszelkich zmianach danych dot. podwykonawców w

trakcie realizacji zamówienia oraz przekazywać informacje na temat nowych podwykonawców, którym

w późniejszym okresie zamierza powierzyć realizację części zamówienia. Jeżeli zmiana albo rezygnacja

z podwykonawcy dotyczyć będzie podmiotu, na którego zasoby powoływał się Wykonawca na zasadach

określonych w art. 22a ust. 1 w celu wykazania spełniania warunków udziału w postępowaniu,

Wykonawca będzie zobowiązany wykazać Zamawiającemu, że proponowany inny podwykonawca lub

Wykonawca samodzielnie spełnia je w stopniu nie mniejszym niż podwykonawca, na którego zasoby

Wykonawca powoływał się w trakcie postępowania o udzielenie zamówienia. Powierzenie wykonania

części zamówienia Podwykonawcom nie zwalnia Wykonawcy z odpowiedzialności za należyte

wykonanie tego zamówienia.

12. Zamawiający żąda od Wykonawcy uczestnictwa w wizji lokalnej, w terminie wyznaczonym przez

Zamawiającego na dzień 31.03.2020 r. godz. 10:00, z zastrzeżeniem, iż zgodnie z art. 9 a ustawy Pzp

oferty mogą zostać złożone jedynie po odbyciu przez wykonawcę wizji lokalnej.

5 ZAŁOŻENIA POCZĄTKOWE ORAZ WYMAGANIA OGÓLNE.

5.1 CEL PROJEKTU

Celem niniejszego projektu jest wdrożenie e-usług poprzez modernizację lub wymianę zintegrowanego

systemu informatycznego, zakup i wdrożenie rozwiązań pomocniczych, integrację z pozostałymi systemami

szpitala oraz systemami zewnętrznymi, a także dostawę urządzeń i oprogramowania systemowego

koniecznego do realizacji projektu.

Podstawowe cele projektu oraz jego założenia zostały zawarte we wniosku o dofinansowanie Zawarte

zostały w treści SIWZ.

5.2 AKTY PRAWNE

Dostarczone rozwiązania teleinformatyczne, ze szczególnym uwzględnieniem dostarczanego i wdrażanego

Oprogramowania, muszą być zgodne z powszechnie obowiązującymi przepisami prawa polskiego

i europejskiego. Musi pozwalać na gromadzenie, przetwarzanie i analizowanie danych i informacji

w obszarach objętych wdrożeniem, na bazie tych danych musi umożliwiać wytwarzanie prawidłowej,

kompletnej, ujętej w obowiązujących przepisach prawa dokumentacji (dokumenty, raporty, wykazy,

oświadczenia, zaświadczenia itp.) , a w tym w szczególności z następującymi aktami prawnymi i ich

późniejszymi aktualizacjami oraz aktami normatywnymi niższego rzędu wydanymi na ich podstawie, jeśli

Strona 6 z 204

zakres funkcjonowania systemu pokrywa się z zakresem przedmiotowym poszczególnych wymienionych

aktów:

- Ustawy z dnia 15 kwietnia 2011 o działalności leczniczej (Dz. U. 2018, poz.2190),

- Ustawy z dnia 28 kwietnia 2011 o systemie informacji w ochronie zdrowia (Dz. U. 2019, poz.408),

- Ustawy z dnia 5 grudnia 1996 r. o zawodach lekarza i lekarza dentysty (Dz. U. 2019, poz.537),

- Ustawy z dnia 27 sierpnia 2004 r. o świadczeniach opieki zdrowotnej finansowanych ze środków

publicznych (Dz.U. 2019, poz.1373),

- Ustawy z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz.U. 2019,

poz.1127),

- Ustawy o statystyce publicznej z dnia 29 czerwca 1995 r. (Dz.U.2019, poz.649)

- Ustawy o ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych (Dz.U.2019.1781) ,

- Rozporządzenia Ministra Zdrowia z dnia 9 listopada 2015 r. w sprawie rodzajów i zakresu

dokumentacji medycznej oraz sposobu jej przetwarzania (Dz.U.2015, poz.2069), wraz z

uwzględnieniem wdrażanych aktualizacji tego zakresu

- Rozporządzenia Ministra Zdrowia z dnia 8 maja 2018 r. w sprawie rodzajów elektronicznej

dokumentacji medycznej (Dz.U.2018, poz.941)

- Rozporządzenia Ministra Zdrowia z dnia 26 czerwca 2019 r. w sprawie zakresu niezbędnych

informacji przetwarzanych przez świadczeniodawców, szczegółowego sposobu rejestrowania tych

informacji oraz ich przekazywania podmiotom zobowiązanym do finansowania świadczeń ze

środków publicznych (Dz.U.2019, poz.1207)

- Rozporządzenia Ministra Zdrowia z dnia 8 września 2015 r.w sprawie ogólnych warunków umów o

udzielanie świadczeń opieki zdrowotnej (Dz.U.2016, poz.1146),

- Rozporządzenia Ministra Zdrowia z dnia 13 kwietnia 2018 r. w sprawie recept (Dz.U.2018,

poz.745),

- Rozporządzenia Ministra Zdrowia z dnia 29 marca 2019 r. w sprawie szczegółowego zakresu danych

objętych wpisem do rejestru podmiotów wykonujących działalność leczniczą oraz szczegółowego

trybu postępowania w sprawach dokonywania wpisów, zmian w rejestrze oraz wykreśleń z tego

rejestru (Dz. U. 2019, poz.605),

- Rozporządzenia Ministra Zdrowia z dnia 17 maja 2012 r. w sprawie systemu resortowych kodów

identyfikacyjnych dla zakładów opieki zdrowotnej oraz szczegółowych zasad ich nadawania

(Dz.U.2019, poz.173),

- Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram

Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w

postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U.2017,

poz.2247) ,

- Zarządzeń Prezesa Narodowego Funduszu Zdrowia w sprawie warunków postępowania dotyczących

zawierania umów o udzielanie świadczeń opieki zdrowotnej,

- Ustawy z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz.U.2019, poz.869),

- Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r.

w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie

Strona 7 z 204

swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE

(Dz.U.UE.L.2016.119.1),

- Ustawy z dnia 11 marca 2004 roku o podatku od towarów i usług (Dz.U.2020.106), wraz z aktami

wykonawczymi

- Ustawy z dnia 29 sierpnia 1997 r. ordynacja podatkowa (Dz.U.2019.900),

- Ustawy z dnia 29 września 1994 r. o rachunkowości(Dz.U.2019, poz.351),

- Ustawy z dnia 26 lipca 1991 r. o podatku dochodowym od osób fizycznych ( Dz.U.2019, poz.1387),

- Ustawy z dnia 15 lutego 1992 r. o podatku dochodowym od osób prawnych(Dz.U.2019, poz.865),

- Ustawy z dnia 29 lipca 2005 r. o przeciwdziałaniu narkomanii (Dz.U.2019.852),

- Ustawy z dnia 5 grudnia 2008 r. o zapobieganiu oraz zwalczaniu zakażeń i chorób zakaźnych u ludzi

(Dz.U.2019.1239), wraz z aktami wykonawczymi

- Ustawy z dnia 6 września 2001 r. prawo farmaceutyczne (Dz.U.2019, poz.499).

- Ustawy z dnia 25 czerwca 1999 r. o świadczeniach pieniężnych z ubezpieczenia społecznego

w razie choroby i macierzyństwa (Dz. U. z 2019 r. poz. 645).

- Ustawy z dnia 13 października 1998 r. o systemie ubezpieczeń społecznych (Dz.U.2019, poz.300).

- Ustawy 26 czerwca 1974 r. kodeks pracy (Dz.U.2019, poz.1040),

- Ustawy z dnia 8 września 2006 r. o Państwowym Ratownictwie Medycznym (Dz.U.2019, poz.993),

- Ustawy z dnia 25 września 2015 r. o zawodzie fizjoterapeuty (Dz.U.2019, poz.952),

- Ustawy z dnia 27 lipca 2001 r. o diagnostyce laboratoryjnej (Dz.U.2019, poz.849),

- Ustawy z dnia 22 sierpnia 1997 r. o publicznej służbie krwi (Dz. U. z 2019 r. poz. 1222).

Powyższy wykaz aktów prawa nie ogranicza ani nie wyłącza przepisów, które oferowane

oprogramowanie musi spełniać, a odpowiedzialnością Oferenta jest zapewnienie zgodności

z wymaganymi przepisami prawa stosownymi do zakresu funkcjonowania przedsiębiorstwa

Zamawiającego.

W okresie gwarancji Oferent będzie zobowiązany dostosować System do zmian przepisów prawa bezpłatnie

w terminie uzgodnionym z Zamawiającym, nie zakłócającym jego pracy, jednak nie dłuższym niż 90 dni od

momentu uprawomocnienia się decyzji o wprowadzeniu zmian. W szczególności zobowiązuje się do

dostosowania systemu do wymiany informacji z systemami centralnymi administracji rządowej

i ubezpieczeniowej projektowanymi w ramach Ustawy o Systemie Informacji w Ochronie Zdrowia.

5.3 PRZEDMIOT ZAMÓWIENIA

Przedmiotem niniejszego postępowania jest wdrożenie e-Usług opisanych w dalszej treści SIWZ z programu

operacyjnego RPO WM 2014-2020, a w tym wdrożenie lub wymiana następujących elementów systemów

informatycznych w przedsiębiorstwie Zamawiającego:

e-Usługi oraz Zintegrowany System Informatyczny

1. Modernizacji lub wymiany zintegrowanego systemu informatycznego obejmującego moduły medyczne

tzw. część „białą” (HIS) w celu umożliwienia wdrożenia e-usług oraz integracją z pozostałymi

elementami systemów informatycznych szpitala, a także obszaru e-zdrowie oraz z przygotowaniem

Strona 8 z 204

szpitalnego systemu informatycznego do planowanego wdrożenia aptecznych systemów robotycznych

automatyzujących obrót produktem farmaceutycznym oraz kontrolę bezpieczeństwa, a w tym:

a. Rozbudowę systemu o moduł żywienia klinicznego;

b. Wdrożenie e-usług (e-rejestracja, e-wyniki, e-ankiety, e-kontrahent);

c. Rozbudowę systemu o moduł Elektronicznej Dokumentacji Medycznej (EDM);

d. Wdrożenie systemu zarządzania ruchem pacjentów;

e. Wdrożenie rozwiązania w udostępnionej chmurze obliczeniowej;

f. Zakup podpisów kwalifikowanych;

g. Zakup sprzętu teleinformatycznego, licencji oraz migracji danych;

h. Rozbudowę systemu o moduł logistyki obrotu produktem leczniczym oraz bezpieczeństwa

farmakoterapii, w tym moduły apteczne,

i. Rozbudowę systemu o moduł wspierający zarządzanie papierowym archiwum dokumentacji

medycznej.

2. Modernizacji lub wymiany modułów administracyjnych, tzw. część „szarą” (ERP), a w tym:

a. finanse i księgowość: podatkowa, statutowa, raportowanie zarządcze,

b. banki, kasy gotówkowe,

c. zobowiązania, należności, windykacja,

d. majątek trwały,

e. gospodarka magazynowa,

f. zapotrzebowania, zamówienia zakupu, księgowanie i rozliczenie zakupu, postępowania

przetargowe, umowy z dostawcami,

g. sprzedaż pozostała, rejestracja sprzedaży detalicznej, rejestracja sprzedaży do NFZ, umowy

z klientami,

h. kadry i płace, rozliczanie grafików i dyżurów, czasu pracy, umów cywilnoprawnych oraz

kontraktów lekarskich,

i. rachunek ekonomiczny projektów i inwestycji,

j. budżetowanie i rozliczenie budżetu,

k. rozliczenia z płatnikami ubezpieczeń,

l. analiza zarządcza, raportowanie statutowe i podatkowe,

m. rozwiązanie klasy BI/OLAP pozwalające na analizę zarządczą danych finansowych oraz

ilościowych pochodzących z budowanego rozwiązania.

Strona 9 z 204

Szczegółowe wymaga dla poszczególnych elementów wyżej wymienionego rozwiązania znajdują

się w dalszej części dokumentacji.

W ramach wdrożenia powyższych elementów zintegrowanego rozwiązania Zamawiający oczekuje poza

realizacją wzajemnej integracji w/w elementów także integrację istniejących systemów Zamawiającego

z modernizowanym rozwiązaniem, a w tym:

a) OptimedNext Dializa,

b) OptiNFZcom,

c) AlleradChazon (Pixel),

d) AlleradExhibeon (Pixel),

e) Centrum LSI (Marcel),

f) Endobase (Olympus).

g) Medok (Elmi),

h) Diagnostyka,

i) System Delphyn (Serologia, Toczenia),

j) Integrację z rozwiązaniami bankowymi (ERP) w tym realizacja „Płatności podzielonej”,

k) Integrację z systemami zewnętrznymi („Biała Lista”, JPK, systemy ZUS, inne wymagane prawem),

l) Kasy fiskalne online i offline,

m) Integracja z systemem obsługującym Laboratorium Histopatologiczne w Szpitalu na Solcu w zakresie

wymiany zleceń oraz wyników badań,

n) Integracja z systemami zewnętrznymi, zgodnie z wymaganiami NFZ, Państwowej Inspekcji

Farmaceutycznej (ZSMOPL), Państwowej Inspekcji Sanitarnej, oraz wspomnianą wcześniej platformą

e-Zdrowie (P1, P2),

o) Platforma elektronicznej wymiany faktur PEF Expert.

Zamawiający oczekuje integracji ze wszystkim systemami zewnętrznymi wymaganymi prawem na

dzień uruchomienia rozwiązania (nie zależnie od obszaru).

5.3.1 System kolejkowy – zarządzanie ruchem pacjentów

System zarządzania kolejkami ma na celu sprawne zarządzanie ruchem Pacjentów w obszarze Poradni

Specjalistycznych. System ma zapewnić uporządkowanie kolejności obsługi pacjentów w szpitalu poprzez

kierowanie pacjenta do odpowiednich gabinetów z zachowaniem pobranego numeru kolejkowego oraz

informowanie pacjentów i numerze w zajmowanych klientach do poszczególnych gabinetów.

System musi umożliwić obsługiwanie minimum (3) trzech niezależnych od siebie miejsc oczekiwania

pacjentów (podsystemów). Dla każdego z tych miejsc musi istnieć możliwość skonfigurowania dowolnej

Strona 10 z 204

ilości kolejek do gabinetów, wspólnych lub charakterystycznych do danych podsystemów. Dla każdej z

kolejki powinna istnieć możliwość nadania unikalnego w skali całego systemu skrótów, który zostanie

wykorzystany w celu zmniejszenia informacji na wydrukach biletów oraz wyświetlaczach stanowiskowych.

System obejmuje kompleksowe wykonanie prac związanych z dostawą i wdrożeniem systemu zarządzania

kolejkami. System ma zostać zainstalowany w Poradniach Specjalistycznych znajdujących się w obszarach

wskazanych przez Zamawiającego oraz posiadać możliwość rozbudowy w przyszłości o kolejne

wyświetlacze i automaty biletowe.

System zarządzania kolejkami obejmować będzie (16) szesnaście gabinetów lekarskich.

Realizacja obejmuje w szczególności:

Dostawę i montaż sprzętu zgodnie z opisem technicznym sprzętu (pkt. Opis techniczny sprzętu),

Dostawę i zainstalowanie licencjonowanego oprogramowania zgodnie z opisem funkcjonalnym

oprogramowania (pkt Opis funkcjonalny sprzętu),

Uruchomienie i konfigurację systemu,

Wykonanie integracji dostarczanego systemu kolejkowego z zaoferowanym ZSI

Przygotowanie dokumentacji użytkowej (instrukcje użytkowania systemu),

Szkolenie pracowników z zarządzania i obsługi wdrożonego systemu kolejkowego.

Integracja z centralnym systemem e-Zdrowie

Istotnym wymaganiem i założeniem niniejszego projektu i postępowania jest zapewnienie przez wdrożone

rozwiązanie integracji funkcjonalnej z systemem teleinformatycznym, o którym mowa w art. 7 ust. 1 ustawy

o systemie informacji w ochronie zdrowia (tj. Dz. U. z 2019 r. poz. 408 z p.zm.), co najmniej w zakresie

opisanym w dokumentach: „Opis usług biznesowych Systemu P1 wykorzystywanych w systemach

usługodawców” oraz „Opis funkcjonalny Systemu P1 z perspektywy integracji systemów zewnętrznych”,

a także Projekt P2 ,,Platforma udostępniania on-line przedsiębiorcom usług i zasobów cyfrowych rejestrów

medycznych" opublikowanych przez CSIOZ.

W zakresie integracji i komplementarności z centralnymi systemami e-zdrowia, na Oferenta będzie

spoczywał obowiązek dostosowania zaoferowanego rozwiązania do wymagań ujętych w dokumentach

publikowanych poprzez CSIOZ, w tym w szczególności do:

Zakresu funkcjonalnego Projektu P1 (system musi posiadać m.in. możliwość wystawiania recept

elektronicznych oraz wystawiania i odbierania skierowań elektronicznych),

Opisu funkcjonalnego Systemu P1 z perspektywy integracji systemów zewnętrznych,

Minimalne wymagania dla systemów usługodawców oraz dokumentacja integracyjna dla obszaru

Zdarzeń Medycznych i Indeksów EDM.

Strona 11 z 204

Korzystania z rejestrów udostępnionych w ramach projektu P2 (dokument CSIOZ: „Funkcjonalności

P2.docx”), w tym w szczególności ZSMOPL.

Dokumenty te dostępne są na stronie internetowej CSIOZ, pod adresem: http://csioz.gov.pl.

W zakresie integralności zaoferowanego Systemu, Oferent powinien uwzględnić i w razie obowiązującego

wymogu wdrożyć poniższe wytyczne i założenia:

Systemy CSIOZ dostępne będą dla odpowiednio zarejestrowanych w CSIOZ systemów

usługodawców i systemów regionalnych wyłącznie poprzez standardowe interfejsy Web

Services. Wymagane jest dwustronne uwierzytelnianie systemów nawiązujących komunikację, a

także podpisywanie komunikatów certyfikatem dostarczanym bądź wskazanym przez CSIOZ.

Komunikaty przesyłane do systemów e-Zdrowie muszą być podpisane elektronicznie certyfikatem

wydanym przez usługodawcę rozwiązania zgodnie z aktualnie obowiązującymi wymaganiami.

Wymagania w zakresie rodzaju stosowanego certyfikatu mogą ulec zmianie w wyniku wejścia w

życie Rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 910/2014 z dnia 23 lipca 2014r.

w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji elektronicznych

na rynku wewnętrznym oraz uchylające dyrektywę 1999/93/WE (Dz.U.UE.L.2014.257.73 , tzw.

rozporządzenie eIDAS) lub wprowadzenia centralnych rozwiązań w zakresie uwierzytelniania

użytkowników w obszarze e-zdrowia.

W przypadku informacji o zdarzeniu medycznym – obowiązuje Model Informacji o Zdarzeniu

Medycznym i Indeksie Dokumentacji Medycznej (dalej: EDMiZM) publikowany przez CSIOZ.

W przypadku rejestru (indeksu) elektronicznej dokumentacji medycznej – obowiązuje EDMiZM

publikowany przez CSIOZ

Zgoda pacjenta na udostępnienie jego dokumentacji medycznej – funkcjonalność ta jest wymagana i

powinna być zgodna z modelem dokumentu zgody oraz modelami interfejsów pozwalających na

wnioskowanie o zgodę, które zostaną opublikowane przez CSIOZ.

Wymiana elektronicznej dokumentacji medycznej (dalej: EDM) – funkcjonalność ta jest wymagana i

powinna być zgodna z modelem wniosku i dokumentu udostępnienia oraz modelami interfejsów,

które zostaną opublikowane przez CSIOZ.

Jednocześnie, zaoferowany system powinien spełniać następujące założenia funkcjonalne:

Prowadzenie i wymianę Elektronicznej Dokumentacji Medycznej (EDM), w tym indywidualnej

dokumentacji medycznej (wewnętrznej, zewnętrznej), uwzględniać musi rozwiązania

umożliwiające zbieranie przez podmiot udzielający świadczeń opieki zdrowotnej jednostkowych

danych medycznych w elektronicznym rekordzie pacjenta oraz tworzenie EDM zgodnej co

najmniej ze standardem HL7 CDA, opracowanym

i opublikowanym przez CSIOZ – Polską Implementacją Krajową HL7 CDA (tzw. IG).

System powinien uwzględniać funkcjonalności dotyczące prowadzenia repozytorium EDM (z

obsługą przechowywania EDM) oraz uwzględniać rozwiązania zapewniające wymianę EDM

pomiędzy repozytorium Zamawiającego a Platformą P1. Platforma P1 będzie zawierała katalog

EDM, w którym znajdować się będą informacje o EDM tworzonym i przechowywanym u

Zamawiającego.

Strona 12 z 204

Repozytorium EDM powinno realizować, co najmniej usługę przyjmowania, archiwizacji i

udostępniania EDM zgodnej z HL7 CDA, a w przypadku repozytoriów badań obrazowych,

przyjmowania, archiwizacji i udostępniania obiektów DICOM.

Zaoferowany Szpitalny System Informatyczny musi być dostosowany do współpracy z systemem, o

którym mowa w art. 33a ustawy z dnia 8 września 2006r. o Państwowym Ratownictwie medycznym

(Dz. U. z 2019 r. poz. 993, 1590)

Zaoferowany Szpitalny System Informatyczny musi być dostosowany do współpracy z systemem, o

którym mowa w art. 17 Ustawy z dnia 22 sierpnia 1997 r. o publicznej służbie krwi (Dz. U. z 2019 r.

poz. 1222).

Zaoferowany system musi być zintegrowany w zakresie wykorzystania Rejestrów Medycznych

dostępnych w systemie P2 (https://rejestrymedyczne.csioz.gov.pl/) w celu weryfikacji i standaryzacji

danych oraz rejestracji podmiotów lub weryfikacji podmiotów udostępnionych w ramach rejestrów

e-Zdrowie, a w szczególności wykorzystania:

o Rejestru Produktów Leczniczych,

o Rejestru Systemów Kodowania,

Ale także innych rejestrów dostępnych w tym rozwiązaniu.

5.3.2 Dostawa Sprzętu Komputerowego oraz oprogramowania systemowego i narzędziowego

Stacje robocze

Zamawiający oczekuje dostawy sprzętu komputerowego – stacji roboczych pod wdrażany system w ilości 50 szt.

o parametrach optymalnych dla realizacji właściwych zadań przez użytkowników na tych stacjach, jednak nie gorszych

niż podane w Załączniku nr 1 do SIWZ.

Platforma sprzętowa i oprogramowanie systemowe

Zamawiający oczekuje dostawy podstawowej infrastruktury serwerowej pod wdrażane rozwiązanie w tym

postępowaniu, w postaci serwerów fizycznych – hostów pod maszyny wirtualne, w terminie uzgodnionym z dostawcą i

wymaganym do prawidłowej realizacji projektu, w ilości:

- Serwery bazodanowe – 2 szt.

- Serwery aplikacyjne – 2 szt.

zgodnych ze specyfikacją podaną w Załączniku nr 2.

Wraz z dostawą serwerów zamawiający oczekuje dostawy właściwego oprogramowania systemów operacyjnych oraz

bazodanowych w ilości uzasadnionej zamawianą ilością maszyn fizycznych i oczekiwaną ilością maszyn wirtualnych

zgodnie z wymaganiami zaproponowanego rozwiązania systemu zintegrowanego.

Dostarczona platforma serwerowa będzie posadowiona w wyznaczonej lokalizacji własnej lub wyznaczonej kolokacji.

Budowa właściwego dostępu sieciowego do tak zbudowanej platformy serwerowej będzie zadaniem Zamawiającego.

Urządzenia rozwiązania organizacji ruchu chorych w przychodniach – system kolejkowy

W ramach postępowania Zamawiający oczekuje dostawy kompletnego zintegrowanego rozwiązania kolejkowego do

zarządzania ruchem chorych opisanego w części OPZ, obsługującego docelową liczbę gabinetów w ilości 16,

a w szczególności:

Strona 13 z 204

Lp. Element Ilość sztuk

1 Automat biletowy 3

2 Wyświetlacz stanowiskowy LED 4 znakowy 3

3 Serwer zarządzający 1

4 Drukarka biletowa do rejestracji 3

5 Monitor gabinetowy 16

6 Monitor centralny recepcji 1

Specyfikacja techniczna zamawianych urządzeń znajduje się w Załączniku nr 3.

Silniki baz danych i inne oprogramowanie narzędziowe

Oferent dostarczy właściwe dla wdrażanego oprogramowania (wraz z BI) silniki baz danych

(oprogramowanie) typu SQL wraz z niezbędną liczbą licencji do pracy wyżej wymienionego

oprogramowania w modelu opłaty jednorazowej, nieograniczonych czasowo, obejmujących ilość

użytkowników równą ilości użytkowników wdrażanych systemów. Dla pewności zakłada się, że

użytkownicy poszczególnych modułów nie pokrywają się.

5.3.3 Inne wymagania

- Przedmiot zamówienia musi być dostarczany i wdrożony w całości do siedziby Zamawiającego (poza

platformą serwerową, która może zostać wdrożona w wyznaczonej kolokacji).

- W ramach realizacji projektu Oferent dostarczy następujące usługi i będzie za nie odpowiedzialny:

- Dostawa, wdrożenie, instalacja i utrzymanie kompletnych środowisk rozwojowych, testowych,

szkoleniowych oraz pozostałych koniecznych do efektywnego przeprowadzenia projektu

wdrożeniowego wraz z niezbędnymi licencjami na czas realizacji projektu oraz trwania serwisu

gwarancyjnego (niezbędnych do jego realizacji) w okresie trwania ww. usług. Zamawiający nie

przewiduje dostawy własnego, dodatkowego sprzętu ani oprogramowania na ten cel.

- Szkolenia personelu Zamawiającego w zakresie obsługi oprogramowania aplikacyjnego, oraz

oprogramowania bazodanowego, systemowego, narzędziowego i pozostałych dostarczonych

w ramach projektu wdrożeniowego zgodnie z zakresem odpowiedzialności poszczególnych profili

użytkowników.

- Migracja danych w tym słownikowych, kartotekowych, bilansów otwarcia koniecznych do

uruchomienia oraz niezakłóconej kontynuacji działalności operacyjnej oraz raportowej

Zamawiającego – tak automatyczna jak i ręczna.

- Dostosowywanie wdrożonych systemów do zmieniających się przepisów prawa, bez dodatkowych

opłat po stronie Zamawiającego, w terminach uzgodnionych z Zamawiającym, jednak nie

dłuższych niż do momentu wejścia zmian prawa w życie, w całym okresie realizacji projektu

wdrożeniowego oraz trwania usługi gwarancyjnej.

Strona 14 z 204

- Utrzymanie w ruchu wdrożonego i przekazanego do eksploatacji oprogramowania przez okres min.

36 miesięcy od rozpoczęcia eksploatacji (wsparcie w administracji).

- Zarządzanie projektem wdrożeniowym, zgodnie z uzgodnioną miedzy stronami metodyką

wdrożeniową w tym wykonanie wszystkich innych niezbędnych czynności koniecznych do

wdrożenia w/w oprogramowania zgodnie z najlepszą praktyką rynkową.

- Wszystkie dostarczane:

Produkty (rozumiane jako elementarny efekt działań/prac/dostaw objętych całym zakresem

Przedmiotu Zamówienia wykonywanych przez Wykonawcę podczas realizacji Umowy

w poszczególnych Etapach),

Komponenty (rozumiane jako integralna część dostawy i wdrożenia Przedmiotu Zamówienia,

składający się przynajmniej z jednego Produktu lub wielu Produktów powiązanych ze sobą

merytorycznie) podlegają usługom projektowania, dostaw, instalacji, konfiguracji i wdrożenia.

- Usługi projektowania, instalacji, konfiguracji i wdrożenia Oferent przeprowadzi zgodnie z zapisami

OPZ w uzgodnieniu z Zamawiającym zgodnie z obowiązującymi przepisami, zasadami wykonywania

projektów teleinformatycznych oraz najlepszymi praktykami w ich realizacji. Oferent jest zobowiązany

do realizacji Przedmiotu Zamówienia zgodnie z zasadami i wytycznymi Zamawiającego, zapisami OPZ

oraz Umowy.

- Ilekroć w niniejszym OPZ Zamawiający użył w opisie oznaczeń norm, aprobat, specyfikacji

technicznych i systemów odniesienia, o których mowa w art. 30 ust. 1-3 Pzp należy je rozumieć jako

przykładowe. Zamawiający zgodnie z art. 30 ust. 4 ustawy Pzp dopuszcza produkty równoważne

opisywanym w treści SIWZ. Jeżeli zapisy uszczegóławiające przedmiot zamówienia wskazywałyby w

odniesieniu do rozwiązań, materiałów lub urządzeń znaki towarowe lub pochodzenie Zamawiający,

zgodnie z art. 29 ust. 3 ustawy PZP, dopuszcza składanie ofert na „produkty” równoważne. Wszelkie

„produkty” pochodzące od konkretnych producentów określają minimalne parametry jakościowe i

cechy użytkowe, jakim musi odpowiadać produkt, aby spełnić wymagania stawiane przez

Zamawiającego i stanowią wyłącznie wzorzec jakościowy przedmiotu zamówienia. Poprzez zapis dot.

minimalnych wymagań parametrów jakościowych Zamawiający rozumie wymagania materiałów,

sprzętu i urządzeń zawarte w ogólnie dostępnych źródłach, katalogach, stronach internetowych

producentów. Operowanie przykładowymi nazwami producenta ma jedynie na celu doprecyzowanie

poziomu oczekiwań Zamawiającego w stosunku do określonego rozwiązania. Tak więc posługiwanie

się nazwami producentów /produktów/ ma wyłącznie charakter przykładowy. Zamawiający, przy opisie

przedmiotu zamówienia, wskazując oznaczenie konkretnego producenta (dostawcy) lub konkretny

produkt, dopuszcza jednocześnie produkty równoważne o parametrach jakościowych i cechach

użytkowych, co najmniej na poziomie parametrów wskazanego produktu, uznając tym samym każdy

produkt o wskazanych parametrach lub lepszych. W takiej sytuacji Zamawiający wymaga złożenia

stosownych dokumentów, wykazujących spełnienie przez produkty równoważne ww. parametrów i

cech.

- Oferent musi dostarczyć wszelkie urządzenia i elementy, które są niezbędne do prawidłowego

funkcjonowania całości. W przypadku, gdy w trakcie realizacji Przedmiotu Zamówienia okaże się, że

brakuje jakiegokolwiek urządzenia i/lub elementu, którego brak spowoduje nieprawidłowe

funkcjonowanie całości Przedmiotu Zamówienia, Oferent dostarczy je na własny koszt.

Strona 15 z 204

- Zamawiający wymaga aby zaoferowane rozwiązanie (system) było rozwiązaniem istniejącym,

działającym, gotowym do wdrożenia i zapewniającym realizację wszystkich wymaganych w SIWZ

(w szczególności OPZ) funkcjonalności na dzień składania ofert i nie może być w fazie opracowywania,

budowy, testów, projektowania itp.

- Wszelkie dostarczane urządzenia:

Muszą być fabrycznie nowe, pochodzić z autoryzowanego kanału sprzedaży producenta

i reprezentować model bieżącej linii produkcyjnej. Nie dopuszcza się urządzeń: demonstracyjnych

lub powystawowych.

Nie dopuszcza się urządzeń posiadających wadę prawną w zakresie pochodzenia sprzętu, wsparcia

technicznego i gwarancji producenta.

Elementy, z których zbudowane są urządzenia muszą być produktami producenta urządzeń lub być

przez niego certyfikowane oraz całe muszą być objęte gwarancją producenta.

Urządzenia i ich komponenty muszą być oznakowane w taki sposób, aby możliwa była

identyfikacja zarówno produktu jak i producenta.

Urządzenia muszą być dostarczone Zamawiającemu wraz z oryginalnymi opakowaniach

producenta.

Do każdego urządzenia` musi być dostarczony komplet standardowej dokumentacji w dla

użytkownika w języku polskim lub angielskim w formie papierowej lub elektronicznej.

Gwarancja i serwis na urządzenia musi być świadczony przez firmę autoryzowaną przez

producenta lub jego przedstawicielstwo w Polsce w przypadku gdy Oferent nie posiada takiej

autoryzacji.

Urządzenia na etapie dostawy od producenta do Zamawiającego nie mogą podlegać modyfikacjom.

Zachowanie integralności i wiarygodności dokumentacji

System powinien współpracować z serwerem autentykacji użytkowników wykorzystującym posiadaną przez

Zamawiającego domenę Windows. System powinien dawać możliwość podpisywania eksportowanej

dokumentacji, wydruków i raportów certyfikatem użytkownika (kwalifikowanym lub nie).

System powinien zapewniać zarządzanie uprawnieniami dostępu użytkowników do poszczególnych

elementów systemu, funkcji, formatek, raportów, danych poprzez system profili lub ról użytkowników

odzwierciadlający role biznesowe tych użytkowników w realizacji procesów biznesowych oraz realizujących

segregację odpowiedzialności.

System powinien posiadać zintegrowany mechanizm zarządzania uprawnieniami wspólny dla

funkcjonalności ZSI oraz BI (ten sam model uprawnień: grup, profili, ról użytkowników) przynajmniej na

poziomie jednorodnej autentykacji użytkowników (domena Windows).

Żadna transakcja w systemie, w tym w szczególności księgowa, nie może być usuwana przez użytkownika w

sposób uniemożliwiający jej odtworzenie jak też skuteczny audyt. Usunięcie wpisu, transakcji, oznacza

jedynie jego faktyczną dezaktywację lub inne oznaczenia jako nieaktualny. Takie usunięcie lub modyfikacji

wpisu może dokonać osoba dokonująca wpisu lub osoba posiadająca specjalne wyodrębnione uprawnienie

Strona 16 z 204

do tych operacji. Fakt ten musi zostać odnotowany w systemie dla celów audytowych wraz z zachowaniem

historii zmiany to jest: oznaczenia osoby dokonującej zmiany, czasu dokonania zmiany oraz zachowania

wersji z przed dokonania zamiany. Jako spełnienie wymogu nie będzie uważane jedynie zapisywanie logu

transakcji i wyszukiwanie zmian na poziomie administratora bazy danych.

System musi zapewniać możliwość audytowania tworzenia, zmiany i usuwania rekordów (audittrial).

Zarządzanie centralnymi danymi słownikowymi

Wdrażane rozwiązanie powinno umożliwiać zastosowanie zarządzania słownikami danych (masterdata)

przynajmniej w zakresie:

audytowalności tworzenia i zmian danych,

uniemożliwienia usuwania danych, a jedynie ich dezaktywacji,

zatwierdzania zmian w danych (np. danych dostawców, klientów, pracowników) dwu lub

trzypoziomowo – przepływy pracy,

jednorodności danych (spójnych, pojedynczych, wspólnych słowników dla wszystkich modułów

systemu),

zarządzania rekordami, w tym automatycznej dezaktualizacji danych (czas życia rekordów),

możliwości anonimizacji danych na żądanie właściciela danych, zmiany danych na żądanie, z

pełnymi logowanie zmian i powodów zmian – zgodnie z obowiązującymi przepisami prawa,

śledzenia zmian w danych osobowych, audytowanie zmian, ograniczenie do przetwarzania

danych osobowych zgodnie z wymaganiami RODO,

jednorodności danych (spójnych, pojedynczych, wspólnych słowników dla wszystkich modułów

systemu),

pojedynczego, spójnego wprowadzania informacji „tylko jedne raz” do całego systemu, tzn.

dany rekord (np. dane pacjenta, klienta, dostawcy, indeksu magazynowego) powinien być

wprowadzony do systemu tylko jedne raz i w razie potrzeby propagowany w inne jego części

jeśli to jest konieczne, jak także powinien być dostępny wszędzie tam gdzie proces tego

przewiduje i jest to biznesowo uzasadnione.

Integracja rozwiązania wewnętrzna oraz zewnętrzna

Celem Zamawiającego jest zakupienie i wdrożenie zintegrowanego systemu informatycznego w którym

dane, funkcje i procesy biznesowe będą spójne i jednolicie obsługiwane w całym systemie oraz systemach z

nim zintegrowanych.

o Wewnętrzna spójność pomiędzy modułami systemu

Wymagana jest integracja pomiędzy poszczególnymi modułami systemu. Integracja o której mowa musi

polegać co najmniej na następujących elementach:

integracja w zakresie weryfikacji uprawnień użytkowników - jeżeli użytkownik jest zalogowany do

jednego modułu może przesłać i odczytać dane z innego modułu bez konieczności dodatkowej

autoryzacji,

integracja semantyczna – moduły muszą w sposób jednoznaczny identyfikować informacje wymieniane

pomiędzy nimi. Integracja musi uwzględniać integrację pojęciową jak i słownikową. Jeżeli moduły

korzystają z różnych słowników Wykonawca musi zapewnić opracowanie i utrzymywanie tabeli

przekodowań,

Strona 17 z 204

wspólny model danych – poszczególne moduły muszą pracować na wspólnym modelu danych,

tzn. przechowywać dane we wspólnych, współdzielonych tabelach, co najmniej w obszarach „białym”

(HIS) oraz „szarym” (ERP), a pomiędzy nimi wymieniać informacje w sposób „przezroczysty” dla

użytkownika, tj. bez jego interakcji.

Oznacza to też, że wymiana informacji musi odbywać się w sposób automatyczny i elektroniczny bez

konieczności ręcznego przepisywania danych pomiędzy systemami.

o Integracja z systemami zewnętrznymi (trzecimi).

Integracyjna wymiana danych pomiędzy ZSI oraz systemami zewnętrznymi powinna odbywać się z

wykorzystaniem właściwych standardów i technologii odpowiednich dla tych systemów, a w szczególności

z wykorzystaniem standardów branżowych, takich jak:

o standard HL7 jako podstawowa technologia wymiany danych pomiędzy ZSI i innymi

systemami własnymi Szpitala jak i systemami zewnętrznymi,

o w przypadku gdy to nie jest technicznie możliwe formatem wymiany danych pomiędzy

integrowanymi systemami może być XML oraz webserwisy (SOAP, REST).

o dopuszcza się też użycie mechanizmów SQL, ETL jeśli odbywa się ona w pełni

automatycznie. Zastosowanie innych mechanizmów musi zostać wcześniej uzgodnione z

Zamawiającym.

o Komunikacja pomiędzy integrowanymi systemami powinna być szyfrowana. W innych

przypadkach konieczna jest zgoda Zamawiającego.

Wszystkie technologie wymiany danych użyte przez Wykonawcę powinny być wcześniej uzgodnione

i zatwierdzone przez Zamawiającego w celu utrzymania zgodności z polityką budowy rozwiązań

systemowych w przedsiębiorstwie Zamawiającego.

Intencją Zamawiającego jest unikanie technologii niezapewniających bezpieczeństwa lub oferujących niski

poziom bezpieczeństwa wymiany danych, jak też nie wspieranych przez środowisko informatyczne

Zamawiającego, takich jak np.: wymiana danych poprzez pliki składowane w sieci (txt, csv, ANSI), czy

protokoły ftp, SQL, jeżeli wymiana danych odbywa się kanałami nie oferującymi szyfrowania danych lub za

pośrednictwem niezaszyfrowanych zbiorów danych.

Wymiana danych co do zasady powinna oferować możliwość audytowania wymienionych danych pomiędzy

systemami oraz sygnalizować wszystkie błędy komunikacji pomiędzy punktami końcowymi.

o TERMIN REALIZACJI PRZEDMIOTU ZAMÓWIENIA

Termin realizacji całości Przedmiotu zamówienia: nie później niż w tym zgodnie z podziałem na etapy:

Etap Zakres prac obejmuje Termin zakończenia

I Analiza przedwdrożeniowa Do 60 dni od podpisania umowy

II. Dostawa, instalacja, konfiguracja i wdrożenie

oprogramowania i sprzętu komputerowego. Do 30 dni od zakończenia etapu I

Strona 18 z 204

III.

Instalacja oraz konfiguracja niezbędnych baz danych

na potrzeby Systemu, a także dostawa i instalacja

licencji na oprogramowanie

Do 30 dni od zakończenia etapu II

IV. Wdrożenie Do 60 dni od zakończenia etapu III

V. Uruchomienie e-usług Nie dłużej niż 30 dni od zakończenia etapów

II, III i IV.

VI. Odbiór końcowy Przedmiotu Zamówienia Do 31 grudnia 2020 r.

Oferent zobowiązany jest przedstawienia szczegółowego planu wdrożenia (harmonogramu) przed jego

rozpoczęciem, wraz ze strukturą planowanych zadań oraz aktualizację planu wdrożenia co najmniej raz

w miesiącu na potrzeby

5.4 ORGANIZACJA WDROŻENIA

5.4.1 Założenia podstawowe

- Przedmiot Zamówienia będzie realizowany w oparciu o opracowany przez Oferenta i zaakceptowany

przez Zamawiającego harmonogram wdrożenia, a następnie odpowiednio aktualizowany w toku

realizacji Przedmiotu Zamówienia.

- Oferent w Harmonogramie wdrożenia musi uwzględnić w szczególności podział na zadania takie jak

projektowanie, dostawy, usługi instalacji/konfiguracji, testowanie, wdrożenie i odbiory.

- Oferent umożliwi Zamawiającemu udział we wszystkich pracach realizowanych przez Wykonawcę

w ramach realizacji Przedmiotu Zamówienia (m.in. w czasie projektowania, dostawach,

instalacji/budowie, konfiguracji i wdrożeniu i testowaniu).

- Oferent zobowiązany jest do udziału w cyklicznych naradach przeglądu prac w siedzibie

Zamawiającego. Zamawiający przewiduje częstotliwość narad maksymalnie do 1 w miesiącu chyba że,

nadzwyczajna sytuacja w realizacji przedmiotu umowy wymagała będzie częstszych spotkań.

- Oferent zobowiązany jest przeprowadzić dostawy Przedmiotu Zamówienia w dokładnych terminach

i godzinach uzgodnionych z Zamawiającym.

- W przypadku dostarczania Sprzętu komputerowego musi być on oznakowany w taki sposób, aby

możliwa była identyfikacja systemowa zarówno produktu jak i producenta, pochodzić z oficjalnych

kanałów dystrybucji producentów i dostarczony w oryginalnych opakowaniach fabrycznych.

- Wdrożenie należy rozumieć jako szereg uporządkowanych i zorganizowanych działań mających na celu

wykonanie Przedmiotu Zamówienia.

- Wdrożenie będzie realizowane w ramach powołanych do tego celu struktur organizacyjnych po stronie

Oferenta. Na etapie analizy przedwdrożeniowej Oferent przygotuje informacje na temat struktury

organizacyjnej Zespołu Oferenta zajmującej się realizacją Przedmiotu Zamówienia, w ramach której

muszą zostać powołane minimum następujące role:

o Kierownik Projektu ze strony Oferenta,

o Zespół Analityczny ze strony Oferenta

o Zespół Wdrożeniowy ze strony Oferenta.

- Wdrożenie muszą realizować osoby wymienione w ofercie Oferenta, przy czym:

o Osoby Zespołu Oferenta muszą być dyspozycyjne w trakcie wykonywania prac,

Strona 19 z 204

o Oferent przekaże Zamawiającemu wykaz numerów telefonów kontaktowych do osób biorących

udział w realizacji Przedmiotu Zamówienia po stronie Oferenta.

- Oferent zorganizuje prace tak, aby w maksymalnym stopniu nie zakłócać ciągłości funkcjonowania prac

u Zamawiającego.

- Obiekty podlegające inwestycji (obiekty służby zdrowia w których świadczone są usługi medyczne) są

użytkowane w trybie ciągłym w czasie godzin pracy przez cały okres wykonywania Przedmiotu

Zamówienia, co może powodować utrudnienia w miejscu prowadzenia prac. Nie ma możliwości

całkowitego wyłączenia i zamknięcia w/w obiektów lub ich części na czas realizacji Przedmiotu

Zamówienia. Poszczególne prace będą realizowane etapowo, tak aby zachować ciągłość świadczenia

usług medycznych.

- Oferent musi uwzględnić, że wszystkie prace wykonywane będą w użytkowanych obiektach przy

dużym ruchu pracowników i chorych, tzn. organizacja prac powinna przede wszystkim zapewniać

bezpieczeństwo przebywających w oddziałach pracowników i chorych oraz zachowanie ciszy nocnej

w godzinach właściwych dla Zamawiającego.

- Oferent dostarczy i zapewni podczas trwania Umowy aplikację internetową będącą Systemem zgłoszeń

i obsługi Wad oraz stanowiąca repozytorium Dokumentacji dla potrzeb realizacji Przedmiotu

Zamówienia.

5.4.2 Wymagania dotyczące szkoleń.

- Zamawiający oczekuje, że Oferent przedłoży w ofercie propozycję szkoleń personelu Zamawiającego

z podziałem na bloki tematyczne, długość trwania oraz ilość przewidzianych teoretycznie uczestników

poszczególnych szkoleń, a w tym:

o administrowanie wdrożonymi bazami danych i innymi komponentami technicznymi,

o administrowanie poszczególnymi modułami oprogramowania w tym poprzez zmianę ustawień tych

modułów,

o eksploatacji wdrożonych modułów oprogramowania zgodnie z opracowanymi procedurami oraz

instrukcjami stanowiskowymi (dokumentacją użytkowników) w podziale na bloki tematyczne

i odpowiednie grupy,

- Zamawiający, w ramach szkolenia użytkowników, przewiduje szkolenia grupowe oraz indywidualne.

- Zamawiający przewiduje przeszkolenie całego personelu w ilości odpowiadającej ilości licencji

użytkowników.

- Administratorów systemów (2 osoby) należy przeszkolić w pełnym zakresie wdrażanych systemów.

- Szkolenia nie mogą odbywać się w grupach większych niż 10 osób.

- W ramach przeprowadzonych szkoleń Oferent zapewni użytkownikom dostęp do systemu testowego

skonfigurowanego podobnie oraz zawierającego przykładowe ale adekwatne dane umożliwiającego

samodzielne dokonywanie ćwiczeń z systemem podczas szkoleń oraz poza nimi (nauka własna),

podczas trwania projektu i w całym okresie gwarancji. System szkoleniowy (testowy) powinien

umożliwiać przeprowadzanie tych samych operacji o odtworzenia procesów co system produkcyjny.

- System szkoleniowy powinien umożliwiać ćwiczenia co najmniej 10 użytkownikom jednocześnie.

- Szkolenia grupowe winny się odbywać w podziale na grupy zawodowe, a tym samym w podziale na

poszczególną funkcjonalność modułów.

- Czas szkolenia z danego modułu systemu dla danej grupy zawodowej powinien uwzględniać stopień

skomplikowania modułu.

Strona 20 z 204

- Każde szkolenie grupowe winno zakończyć się krótkim testem sprawdzającym wiedzę szkolonego

personelu uzyskaną podczas szkolenia oraz podpisaniem protokołu z realizacji szkolenia zawierającym:

czas trwania szkolenia, jego zakres merytoryczny, wyniki testu końcowego, wykaz uczestników.

Protokół winien być podpisany i przez osoby szkolące i uczestniczące w szkoleniu.

- Oferent po zawarciu umowy dostarczy harmonogram szkoleń do akceptacji Zamawiającego.

- Zamawiający nie dopuszcza szkoleń on-line lub samodzielnych dla natywnych aplikacji dostarczonego

rozwiązania (działających bezpośrednio pod kontrolą systemu Windows), a dopuszcza szkolenia on-line

lub samodzielne szkolenia dla funkcji dostępnych przez portale WWW.

5.5 WYMAGANIA DOTYCZĄCE PERSONELU OFERENTA

- Wdrożenie i szkolenie muszą realizować osoby wymienione w ofercie Oferenta w Wykazie osób

przedstawionym do realizacji umowy.

- Zamawiający wymaga, by prace instalacyjne i wdrożeniowe systemu, szkolenia grupowe

i indywidualne personelu Zamawiającego przeprowadzały osoby posiadające doświadczenie w zakresie

produktów, których dotyczyć będzie instalacja oraz wdrożenie.

- Osoby wykonujące prace instalacyjne i wdrożeniowe oraz szkolące muszą być dyspozycyjne w trakcie

trwania prac instalacyjnych, wdrożeniowych oraz szkoleń. Wymagany jest stały kontakt roboczy

z Zamawiającym.

- Oferent przekaże Zamawiającemu wykaz numerów telefonów kontaktowych do osób wykonujących

prace instalacyjne, wdrożeniowe i szkolenia. Stały kontakt oznacza dyspozycyjność osób wykonujących

prace instalacyjne i wdrożeniowe w trakcie trwania prac instalacyjnych i wdrożeniowych w godzinach

pracy Zamawiającego tj. 8:00 do 15:00.

- Zamawiający wymaga, by wszelkie zastępstwa lub trwała zmiana w osobach instalujących

i wdrażających zgłaszana była niezwłocznie przez Wykonawcę, z zastrzeżeniem, że osoba zastępująca

musi posiadać niemniejsze kwalifikacje niż osoba zastępowana. Zastępstwo lub trwała zmiana danej

osoby wymaga akceptacji ze strony Zamawiającego.

- Zamawiający może zażądać zmiany osoby wdrażającej.

5.5.1 Przygotowanie Dokumentacji

W ramach prac Oferent opracuje dla Zamawiającego Dokumentację Przedmiotu Zamówienia (zwaną

dalej Dokumentacja, Dokumentacja PZ), która składa się z nw. zakresów:

o Harmonogram Wdrożenia

o Dokumentacja Analizy Przedwdrożeniowej (DAP)

o Dokumentacja Powykonawcza

Dokumentacja powyższa będzie zawierać bazowe zapisy opisujące budowane rozwiązania, procesy oraz

sposób organizacji prac i wdrożenia. Na podstawie zapisów w Dokumentacji będą prowadzone

i odbierane poszczególne etapy realizowane w ramach Przedmiotu zamówienia. Dokumenty te wraz ze

Specyfikacją Istotnych Warunków Zamówienia (dalej zwanych SIWZ) będę stanowiły podstawę do

weryfikacji wdrożenia w trakcie odbiorów.

Dokumentacja podlega uzgadnianiu i akceptacji Zamawiającego. Akceptacja Harmonogramu wdrożenia

i DAP warunkuje rozpoczęcie prac Oferenta.

Strona 21 z 204

Oferent zobowiązuje się do oznakowania dostarczanego w ramach zamówienia sprzętu, nośników,

dokumentacji dla poszczególnych Zamawiających zgodnie z wytycznymi w zakresie informacji

i promocji projektów dofinansowanych w ramach Regionalnego Programu Operacyjnego Województwa

Łódzkiego na lata 2014-2020. W celu oznakowania dostarczanego sprzętu oraz nośników Oferent

otrzyma od Zamawiającego odpowiednio przygotowane naklejki informacyjne.

Dokumentacja Harmonogramu Wdrożenia oraz Analizy Przedwdrożeniowej DAP zostanie opracowana

w oparciu o wymagania określone w OPZ.

5.5.2 Harmonogram wdrożenia

Oferent zobowiązany jest opracować na podstawie SIWZ szczegółowy harmonogram wdrożenia.

Harmonogram należy przedstawić Zamawiającemu w terminie do 14 dni od podpisania Umowy.

5.5.3 Analiza Przedwdrożeniowa

1) Analiza przedwdrożeniowa, którą należy rozumieć jako zakres czynności do wykonania przez

Wykonawcę mający na celu analizę środowiska biznesowego i informatycznego Zamawiającego.

W wyniku przeprowadzenia Analizy przedwdrożeniowej Oferent przedstawi Zamawiającemu

Dokumentację analizy przedwdrożeniowej (zwana dalej DAP), na podstawie której będzie

realizowany organizacyjnie i technicznie Przedmiot Zamówienia. DAP będzie podlegała

uzgodnieniu i akceptacji Zamawiającego.

2) Dokumentacja Analizy Przedwdrożeniowej DAP powinna zawierać w szczególności:

Skład DAP

ZSI i eUsługi

- wykaz oraz szczegółowy opis i harmonogram budowy ZSI i eUsług

- architekturę ZSI i eUsług

- analizę migracji danych oraz opis sposobu migracji

- przygotowanie planu instalacji Sprzętu komputerowego, serwerowego, macierzy

- określone założenia integracji z innymi systemami informatycznymi, które posiada Zamawiający

- plan pracy na dalsze etapy Wdrożenia

- plan migracji danych z ZSI, który posiada Zamawiający

- szczegółową specyfikację oprogramowania objętego zakresem umowy

- wykaz oraz szczegółowy opis i harmonogram niezbędnych prac konfiguracyjnych

- ustawienia konfiguracyjne urządzeń i oprogramowania wchodzących w skład ZSI

Strona 22 z 204

- propozycje scenariuszy testowych uwzględniających zakres czynności operacyjnych, które należy wykonać w celu

potwierdzenia, że wskazane wymagane funkcjonalności zostały prawidłowo skonfigurowane i działają zgodnie z

opisami procesów

- harmonogram instruktażu personelu oraz administratorów ZSI

Zarządcze

- plan i sposób komunikacji Stron

- plan zarządzania jakością w Projekcie

- plan zarządzania zagadnieniami w Projekcie

- sposób obsługi zmian projektowych,

- plan zarządzania ryzykiem w Projekcie

- skład Zespołu Wdrożeniowego wraz z podziałem na role i zadania poszczególnych członków zespołu

Sprzętu komputerowego

- podział Przedmiotu Zamówienia na Produkty, a następnie ich pogrupowanie w Komponenty

- analizę wymagań Przedmiotu Zamówienia zawierającą opis sposobu realizacji wymagań, sposób testowania i

odbioru

- karty katalogowe potwierdzające spełnienie wymagań

- dokumentacje i plan dostaw

- plan i opis instalacji i wdrożenia systemów wdrażanych wraz ze Sprzętem komputerowym

- plan i opis modernizacji i budowy Sprzętu komputerowego,

- listę Komponentów, które będę podlegały osobnym odbiorom

- szczegółowe uzgodnienia Stron Umowy dotyczące zakresu i sposobu integracji dostarczanych rozwiązań z

istniejącą infrastrukturą,

- zakres prac realizowanych przez podwykonawców,

- szczegółowy zakres i zawartość pozostałej Dokumentacji

- plan Instruktaży stanowiskowych i Administratora oraz sposób ich wykonania

5.5.4 Dokumentacja Powykonawcza

Warunkiem dokonania Odbioru Końcowego jest dostarczenie przez Wykonawcę Dokumentacji

Powykonawczej obejmującej dokumentację użytkową, techniczną i eksploatacyjną. Dokumentacja

Strona 23 z 204

Powykonawcza musi być dostarczona w języku polskim, w wersji elektronicznej w formacie edytowalnym

oraz w co najmniej jednym egzemplarzu papierowym.

W dokumentacji muszą być zawarte opisy wszelkich cech, właściwości i funkcjonalności pozwalających na

poprawną z punktu widzenia technicznego eksploatację rozwiązań.

W szczególności dokumentacja ta powinna zawierać:

1) Pełna charakterystyka licencjonowania wszystkich elementów aplikacji i środowiska;

2) Opis architektury technicznej;

a. wyszczególnienie oraz opis powiązań wszystkich komponentów sprzętowych, systemowych

i aplikacyjnych występujących lub wymaganych do poprawnej pracy aplikacji zgodnie

z wymaganiami wydajności, funkcjonalności i bezpieczeństwa (minimalny, maksymalny,

rekomendowany),

b. dla komponentów innych dostawców, należy dokładnie określić wykorzystywane

i dopuszczalne wersje;

3) Konfiguracja musi obejmować wszystkie urządzenia wdrożone, zainstalowane w ramach budowy

systemu IT;

4) Przykładowy zestaw wymaganych danych konfiguracyjnych obejmuje:

a. serwery – parametry sprzętowe (procesor, pamięć, dyski, karty sieciowe, zasilanie, itp.);

b. sieć (adresacja IP, itp.),

c. podsystem dyskowy (punkty montowania/litery dysków, wolumeny logiczne, grupy wolumenowe,

zasoby dyskowe, RAID, itp.),

d. system operacyjny (parametry jądra, moduły, usługi, stos TCP/IP, itp.),

e. klaster (węzły fizyczne, paczki klastrowe, kolejność przełączania, itp.),

f. listę zainstalowanego oprogramowania, itp.;

g. macierze – parametry sprzętowe (cache, półki dyskowe, dyski, karty/porty fibre channel, itp.),

grupy dyskowe, zasoby dyskowe, maskowanie, kopie biznesowe, replikacja, itp.;

h. infrastrukturę sieciową– parametry sprzętowe (porty fibre channel, aktywne licencje, itp.), fabric,

zonning, aliasy, itp.

5) Opis aplikacji i konfiguracji aplikacji/systemu.

a. opis musi obejmować ogół oprogramowania wdrożonego, zainstalowanego w ramach budowy

systemu IT.

b. opis musi zawierać opis systemu lub systemów informatycznych, zawierający wykaz programów,

procedur lub funkcji, w zależności od struktury oprogramowania, wraz z opisem algorytmów

i parametrów oraz programowych zasad ochrony danych, w tym w szczególności metod

zabezpieczania dostępu do danych i systemu ich przetwarzania, sposobu komunikacji pomiędzy

systemami, zakresu wymienianych danych i sposobu ich szyfrowania.

Strona 24 z 204

c. przykładowy zestaw wymaganych danych konfiguracyjnych obejmuje: wersję oprogramowania,

narzędzia, użytkowników i grupy systemowe, katalog instalacyjny, położenie plików

konfiguracyjnych, pierwotne parametry konfiguracyjne i zmodyfikowane w procesie instalacji,

położenie plików logów, położenie i opis innych kluczowych plików i katalogów, parametry

instancji, itp.;

d. konfiguracja musi obejmować wersję aplikacji, pełen zestaw parametrów konfiguracyjnych

aplikacji wraz z opisem użycia, katalogi instalacyjne, położenie plików konfiguracyjnych,

położenie plików logów, położenie i opis innych kluczowych plików i katalogów, itp.

6) Opis architektury logicznej:

a. schemat i opis powiązań logicznych poszczególnych komponentów i ich rolę

w architekturze.

7) Mapa i opis Interface’ów.

a. interfejsy muszą zawierać szczegółowy opis techniczny, w szczególności zawierać informację o:

typie interfejsu, wykorzystywanych protokołach, portach sieciowych, strukturze interfejsu, itp. oraz

o zakresie wymiany danych i sposobu kontroli prawidłowości działania. W szczególności opis

musi zawierać szczegółową dokumentację procesów wymiany danych pomiędzy osobnymi

systemami medycznymi z uwzględnieniem podania typu komunikacji (HL7 2.x / HL7 3.x / inne)

oraz zestawienie komunikatów.

8) Opis struktur baz danych

a. opis wykorzystywanych struktur danych musi w szczególności zawierać: listę tabel bazy danych

wraz z opisem pól, formaty danych, itp., kryteria walidacji danych wejściowych, opis zmiennych

konfiguracyjnych.

9) Opis wymagań sprzętowych, systemowych, sieciowych, itp.

10) Wymagania dla poszczególnych komponentów architektury, odniesienia do oczekiwanych wymagań

wydajnościowych, funkcjonalnych i bezpieczeństwa (minimalny, maksymalny, rekomendowany).

11) Procedury tworzenia środowisk pomocniczych

a. zasady i procedury tworzenia środowisk (testowych, rozwojowych, raportowych) oraz metod

klonowania i anonimizacji (depersonalizacji)1 danych przenoszonych pomiędzy środowiskami;

12) Procedury eksploatacji.

a. w szczególności dokumentacja zawiera procedury tworzenia/odtwarzania kopii bezpieczeństwa

operacyjnego i kopii zapasowych oraz odtwarzania/kreowania z kopii wszystkich komponentów

aplikacji i środowiska (bazy danych, komponenty serwera aplikacji, klienta itp.);

b. odtworzenia systemów i środowiska informatycznego Zamawiającego po katastrofie

(DisasterRecovery):

1Poprzez ‘anonimizację’ Zamawiający rozumie ‘zakodowanie’ danych dowolną metodą tak, aby usunięte zostały dane

osobowe lub odczytanie tych danych nie było możliwe w sposób trwały i nieodwracalny.

Strona 25 z 204

procedury muszą opisywać kolejne kroki pozwalające na bezpieczne

zatrzymanie/uruchomienie elementu infrastruktury hardware’owej oraz aplikacji i elementów

infrastruktury software’owej, lub całego środowiska sprzętowo-software’owego.

dokumenty obejmują również procedury i instrukcje instalacji krok po kroku środowiska

produkcyjnego „od zera” na:

środowisku fizycznych hostów danego Zamawiającego rozpoczynając od dostarczonego

wirtualizatora,

standardowym zastosowanym systemie operacyjnym dla poszczególnych dostarczonych

systemów informatycznych.

13) Procedury lub instrukcje instalacji, reinstalacji, deinstalacji oraz aktualizacji.

a. szczegółowy opis postępowania w przypadku tworzenia lub zmian w środowisku; jeśli

wykorzystywane są procedury innych dostawców dla standardowych komponentów (np. baz

danych) wystarczy wskazać w dokumentacji szczegółowe odniesienie do procedur

standardowych właściwych dla tych komponentów.

14) Procedury backupowe:

a. zalecany tryb backupu aplikacji i elementów infrastruktury software’owej, oraz zakres

danych podlegających backupowi. Procedury odtworzeniowe, muszą w szczególności

opisywać sposób odtworzenia funkcjonalności aplikacji i elementów infrastruktury

software’owej w przypadku błędu lub awarii.

15) Dokumentacja administracyjna związana z poprawną eksploatacją

a. opis (w postaci procedur lub instrukcji) wszystkich rutynowych czynności administracyjnych dla

aplikacji i systemu informatycznego (dziennych, tygodniowych, miesięcznych itp.) oraz działań

pozwalających na utrzymanie wymaganej dostępności, wydajności i bezpieczeństwa.

b. wymagane jest dostarczenie poprawnych inicjalnych sekwencji realizowanych czynności

administracyjnych i utrzymaniowych i zasad ich aktualizacji i budowy; opis zasad pielęgnacji

i utrzymania aplikacji. Procedury administracyjnepowinny w szczególności zawierać informacje

o okresowych zadaniach, które muszą być wykonane przez administratora, np. weryfikacja

zajętości przestrzeni tabel, konieczność wykonywania analizy tabel, czyszczenia logów, itp.

16) Dokumentacja procesu parametryzacji:

a. wyszczególnienie wszystkich parametryzowanych elementów systemu wraz z opisem ich

znaczenia i dopuszczalnych wartości oraz stosowanych wartości domyślnych.

17) Dokumenty z testów:

a. plan testów, scenariusze testowe i protokoły z testów akceptacyjnych, wydajnościowych,

testów operacji administratora technicznego oraz testów bezpieczeństwa w tym ciągłości

działania (przełączanie, odtwarzanie, weryfikacja poprawności).

18) Dokumentacja wdrożeniowa:

a. dokumentacja powdrożeniowa: zawiera szczegółowy opis wykonanych czynności

instalacyjnych oraz konfiguracyjnych wszystkich komponentów systemu;

Strona 26 z 204

b. dokumentacja parametryzacji: wyszczególnienie wartości wszystkich ustawionych

parametrów użytkowych zarówno samej aplikacji jak i pozostałych komponentów systemu,

parametry systemu operacyjnego oraz parametry sprzętu, w tym konfiguracji środowiska

produkcyjnego (serwery baz danych, serwery aplikacji, inne zastosowane);

c. dokumentacja uruchomieniowa: opisuje wszystkie istotne kroki (czynności) wykonane w

celu pierwszego uruchomienia aplikacji/systemu, w tym opis migracji/konwersji danych,

testy uruchomieniowe;

d. dokumentacja pilotażowa: jeśli był stosowany w trakcie wdrożenia pilotaż jako element

stabilizacji i testów.

19) Wersjonowanie:

a. opis zasad wersjonowania i sposobu patchowania aplikacji.

20) Zalecenia:

a. opis zasad i zaleceń strojenia aplikacji.

21) Instrukcje obsługi i instrukcje użytkowania dla wersji dostarczonego oprogramowania z podziałem na

poszczególne moduły.

22) W zakresie obszarów administratora dokumentacja powinna zawierać dodatkowo co najmniej:

a) opis podstawowych ról użytkowników i zasad ich kreowania;

b) opis zarządzania uprawnieniami użytkownika i tworzenia profili;

c) lista dostępnych uprawnień użytkownika wraz z opisem efektu w zakresie dostępu do danych w

ZSI;

d) opis zarządzania autoryzacją i autentykacją użytkowników.

Wkład do Polityki bezpieczeństwa w zakresie wdrożonego Systemu oraz Instrukcję zarządzania systemem

informatycznym służącym do przetwarzania danych osobowych opracowane zgodnie z wymaganiami

określonymi w Rozporządzeniu Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r.

w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie

swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie

o ochronie danych).

23) Wkład do Polityki Bezpieczeństwa będzie zawierać w szczególności:

a. wykaz zbiorów danych osobowych wraz ze wskazaniem programów zastosowanych do

przetwarzania tych danych;

b. opis struktury zbiorów danych wskazującej zawartość poszczególnych pól informacyjnych i

powiązań między nimi;

c. informacje o sposobie przepływu danych pomiędzy poszczególnymi systemami;

d. opis środków technicznych i organizacyjnych niezbędnych dla zapewnienia poufności,

integralności i rozliczalności przetwarzanych danych.

Strona 27 z 204

5.5.5 Odbiór Etapu/Dokumentacji/Końcowy

1. Odbiory Etapów/Dokumentacji będą się odbywać po zakończeniu określonych prac danego

Etapu/Dokumentacji.

2. Odbiór końcowy Przedmiotu Zamówienia ma na celu potwierdzenie wykonania wszystkich zadań

wynikających z Umowy, w tym odebrania wszystkich Komponentów i Etapów oraz dostarczenia

wymaganej zamówieniem Dokumentacji.

3. Odbiory będą odbywać się zgodnie z IPU stanowiącej Załącznik nr 11 do SIWZ. Na potwierdzenie

odbioru Etapu/Końcowego Strony Umowy podpiszą odpowiednio:

a) Protokół Odbioru Etapu – protokół przygotowany przez Wykonawcę, będący potwierdzeniem

przyjęcia przez Zamawiającego wykonanych przez Wykonawcę prac będących przedmiotem

poszczególnych Etapów.

b) Protokół Odbioru Końcowego – protokół, który po podpisaniu bez zastrzeżeń przez Zamawiającego

oraz Wykonawcę stanowi potwierdzenie wykonania i odbioru Przedmiotu Zamówienia.

5.5.6 Dostawa i instalacja oprogramowania standardowego

1. Oprogramowanie standardowe rozumiane jako oprogramowanie dostarczone i zainstalowane na

sprzęcie komputerowym posiadanym przez Zamawiającego i/lub dostarczanym zgodnie z

IPU, stanowiącymi Załącznik nr 11do SIWZ oraz w istniejących systemach informatycznych

zgodnie z wymaganiami niniejszego Opisu Przedmiotu Zamówienia w taki sposób, aby

zapewnić prawidłowe funkcjonowanie Oprogramowania aplikacyjnego, sprzętu oraz

istniejących systemów informatycznych na wszystkich stanowiskach pracy (stanowiska

komputerowe) Zamawiającego.

2. Dostawa i instalacja zostaną wykonane w lokalizacjach zgodnych z instalacją sprzętu u

Zamawiającego zgodnie z harmonogramem (planem) wdrożenia, jednak nie później niż 14 dni przed

rozpoczęciem pierwszego zadania projektu, które wymaga uruchomienia tego oprogramowania.

3. Oprogramowanie standardowe musi zostać skonfigurowane tak, aby działało poprawnie zgodnie z

jego przeznaczeniem i architekturą Systemu oraz zapewniało prawidłową pracę Oprogramowania

aplikacyjnego.

5.5.7 Dostawa, instalacja, konfiguracja i wdrożenie Oprogramowania aplikacyjnego

- Zadanie dostawy, instalacji, konfiguracji i wdrożenia Oprogramowania aplikacyjnego obejmuje:

o Szpitalny System Informatyczny (HIS, ERP) wraz z integracjami (LIS, RIS, PACS,

patomorfologia, mikrobiologia)

o E-usługi.

- Dostawa i instalacja mają być wykonane w wyznaczonych lokalizacjach Zamawiającego.

- Po zakończeniu prac instalacyjnych Oprogramowanie musi zostać skonfigurowane

i wdrożone w sposób kompleksowy tak, aby oferowało wszystkie funkcjonalności opisane w SIWZ

oraz zgodnie z Dokumentacją i wskazanymi przez Zamawiającego wytycznymi na etapie analizy

przedwdrożeniowej oraz samego procesu wdrażania oczekiwaniami konfiguracyjnymi (w zakresie

opisanych w OPZ wymagań funkcjonalnych).

Strona 28 z 204

- Oprogramowanie aplikacyjne musi zostać zainstalowane przez Wykonawcę

w szczególności z wykorzystaniem Sprzętu dostarczanego przez Wykonawcę

i w środowiskach informatycznych Zamawiającego. Oprogramowanie aplikacyjne musi zostać

zainstalowane i skonfigurowane w sposób kompleksowy na wszystkich stanowiskach

komputerowych Zamawiającego.

Zamawiający na potrzeby realizacji przedmiotu zamówienia przewidział infrastrukturę

i oprogramowanie o parametrach wskazanych w rozdziale III OPZ.

5.5.8 Godziny rozwojowe

Zamawiający w ramach wdrożenia wymaga puli 200 godzin rozwojowych, przez co rozumie pulę godzin do

dyspozycji Zamawiającego na modyfikacje, których nie dało się przewidzieć na etapie budowy niniejszego

dokumentu.

5.5.9 Zestawienia raportowe

Zamawiający w ramach wdrożenia ZSI oczekuje zaimplementowania puli raportów niezbędnych

Zamawiającemu do codziennej pracy z systemem. Listę raportów oraz ich wzory Oferent opracuje w ramach

analizy przedwdrożeniowej.

Zamawiający oczekuje, że system będzie umożliwiał tworzenie raportów formularzowych przez

uprawnionych użytkowników wraz z możliwością dowolnego definiowania pól obligatoryjnych.

Zamawiający nie dopuszcza, aby tworzenie raportów formularzowych wymagało od uprawnionych

użytkowników zaawansowanej wiedzy programistycznej.

Raporty o charakterze tabelarycznym powinny umożliwiać export do formatu arkusza Excel.

5.5.10 Testy

1. W ramach zadania zostaną przeprowadzone wszystkie testy opisane w Dokumentacji. Celem testów

jest weryfikacja przez Zamawiającego, czy wszystkie prace wykonane w trakcie realizacji

Przedmiotu Zamówienia zostały wykonane prawidłowo i zgodnie z założeniami funkcjonalnymi i

jakościowymi. Testy będą przeprowadzane przez Wykonawcę przy współudziale Zamawiającego jak

i wskazanych przez danego Zamawiającego osób i podmiotów zewnętrznych.

2. Pozytywne zakończenie testów wraz z usunięciem wskazanych Wad jest niezbędne aby dla

poszczególnych Komponentów oraz całego Przedmiotu Zamówienia dokonać odbiorów

w ramach poszczególnych Etapów i Odbioru końcowego.

3. Zamawiający ma prawo do weryfikacji należytego wykonania Umowy dowolną metodą,

w tym także z wykorzystaniem opinii zewnętrznego audytora. W szczególności uzgodnienie

określonych scenariuszy testowych nie wyklucza prawa do weryfikacji prac innymi testami i

scenariuszami.

4. Zamawiający w końcowej fazie wdrożenia oczekuje realizacji przez Wykonawcę testów

bezpieczeństwa. Testy obejmować będą swym zakresem:

a. Testy penetracyjne wskazanych zasobów wykonywane metodą white, black lub grey –box.

b. Testy bezpieczeństwa aplikacji wytworzonych i dostarczonych w ramach projektu

wskazanych przez Zamawiającego na etapie Analizy przedwdrożeniowej.

c. Testy poprawności konfiguracji i parametryzacji sprzętu serwerowego oraz sprzętu

sieciowego aktywnego na styku komunkacji z zewnętrzną siecią.

Strona 29 z 204

Testy te będą prowadzone w środowisku produkcyjnym systemu teleinformatycznego w co najmniej

2 iteracjach.

W przypadku zidentyfikowania Błędów lub Wad Oferent jest zobowiązany do ich poprawy przed odbiorem

Przedmiotu Zamówienia.

5.5.11 Dodatkowe zobowiązania Oferenta

1. Wykonanie Przedmiotu Zamówienia z efektywnością oraz zgodnie z praktyką i wiedzą zawodową.

2. Wykonanie w całości Przedmiotu Zamówienia w zakresie określonym w Umowie będącej

załącznikiem nr 11 do SIWZ.

3. Dokonanie z Zamawiającym wszelkich koniecznych ustaleń mogących wpływać na zakres i sposób

realizacji Przedmiotu Zamówienia oraz ciągła współpraca z Zamawiającymi na każdym etapie

realizacji.

4. Stosowanie się do wytycznych i polityk bezpieczeństwa informacji obowiązujących u danego

Zamawiającego.

5. Udzielanie na każde żądanie danego Zamawiającego pełnej informacji na temat stanu realizacji

Przedmiotu Zamówienia.

6. Współdziałanie z osobami wskazanymi przez Zamawiającego.

6 DOSTAWA I WDROŻENIE SZPITALNEGO SYSTEMU

INFORMATYCZNEGO

6.1 WYMOGI DOTYCZĄCE INTEROPERACYJNOŚCI LUB MIGRACJI DLA OFEROWANEGO

ZSI

1) Oferent zobowiązuje się dostarczyć Zamawiającemu wymagane funkcjonalności ZSI w taki sposób, aby

w jak najszerszym zakresie zostały zaspokojone potrzeby Zamawiającego. Zamawiający dopuszcza

wymianę posiadanego obecnie rozwiązania. Koniecznym jest zachowanie pełnej wzajemnej

interoperacyjności nowo wdrażanych modułów/grup funkcjonalności, a także w przypadku rozbudowy,

pełnej interoperacyjności z modułami/grupami/systemami funkcjonalności już funkcjonującymi

u Zamawiającego.

2) Szpitalny System Informatyczny, stanowiący źródło Elektronicznej Dokumentacji Medycznej EDM

musi mieć zaimplementowane i uruchomione mechanizmy integracji oraz zapewnić prawidłową

integrację z systemem EDM,

3) Szpitalny System Informatyczny, jako produkt z zakresu tzw. e-Zdrowia, musi spełniać wymogi

i zalecenia im stawiane, takie jak:

1. Zapewnienie pełnej zgodności z Rekomendacjami dla Kryteriów dostępu, zdefiniowanymi

w wymogach i rekomendacjach Komitetu Sterującego do spraw koordynacji interwencji EFSI

w sektorze zdrowia, które zostały zdefiniowane w załączniku do jego Uchwały Nr 23/2016 z dnia

29 kwietnia 2016 r.

Strona 30 z 204

2. Zapewnienie pełnej zgodności na dzień odbioru z opracowaniami publikowanymi przez Centrum

Systemów Informacyjnych Ochrony Zdrowia.

3. Rozporządzenie Ministra Zdrowia z dnia 9 listopada 2015 r. w sprawie rodzajów, zakresu i wzorów

dokumentacji medycznej oraz sposobu jej przetwarzania (Dz.U. 2015 poz. 2069)

4. Ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (tj. Dz. U. z 2019 r.

poz. 408 z późn. zm.)

5. Zapewnienie komunikacji umożliwiającej wymianę aktualnych danych z rejestrami Platformy

Rejestrów Medycznych (P1 oraz P2), odpowiadających analogicznym rejestrom

zaimplementowanym w modułach ZSI.

6. Zapewnienie wsparcia obsługi dla Karty Specjalisty Medycznego (KSM).

Realizacja niniejszych powyższych wymagań jest jednym z celów projektu objętego niniejszym

postępowaniem i wchodzi w jego zakres.

6.2 DOSTĘPNOŚĆ DOSTARCZANEGO ROZWIĄZANIA

Szpitalny System Informatyczny działa w trybie 24 godzinnym przez wszystkie dni w roku z dostępnością co

najmniej na poziomie 99% w skali miesiąca dla części białej HIS oraz 97% dla części szarej ERP.

System nie jest dostępny, gdy występuje sytuacja uniemożliwiająca wykorzystanie którejś z jego funkcji z

przyczyn leżących wewnątrz Systemu (np. awarii, spadku przepustowości Systemu i wynikającego stąd

przeciążenia Systemu). Planowane prace serwisowe (tzw. down time) odbywają się w godzinach od 2:00

do 5:00. W ciągu jednego miesiąca mogą odbyć się maksymalnie cztery takie przerwy. Czas planowych

prac serwisowych (down time) nie jest liczony jako niedostępność i musi być uzgodniony z Zamawiającym i

przez niego zaakceptowanym w formie pisemnej (mailowej lub w formie pisma).

6.3 WYMAGANY STAN DOCELOWY

Zamawiający oczekuje dostarczenia Szpitalnego Systemu Informatycznego co najmniej z modułami (podział

na moduły jest jedynie umowny i może przebiegać odmiennie dla zaproponowanego rozwiązania):

Nazwa modułu Ilość licencji

Zakłada się że w ramach części medycznej systemu szpitalnego zostaną wdrożone co najmniej

następujące moduły systemu:

Izba przyjęć

SOR

Oddział

Panel lekarski

Ordynacja lekarska

Opieka pielęgniarska

Diety / Żywienie pozajelitowe

Leki – zlecenia / realizacja

Open (bez

ograniczeń na

liczbę

użytkowników).

W chwili obecnej

Szpital posiada

742 aktywne

konta

użytkowników w

części białej.

Strona 31 z 204

Blok operacyjny

Blok porodowy

Bank krwi – zlecenia

Zakażenia szpitalne

Apteka

Apteczka Oddziałowa

Zlecenia i skierowania

Zlecenia laboratorium

Punkt pobrań

Wyniki pacjenta

Recepty

Rehabilitacja

Rozliczenia z NFZ

Rozliczenia komercyjne

Terminarz

Gabinet

Gabinet POZ

Obsługa kolejek

Stomatologia

Laboratorium / Diagnostyka obrazowa / Sterylizacja

Zarządzanie aparaturą medyczną

Transport medyczny

Dializy

Medycyna pracy

e-usługi

Raporty BI

Kalkulacja kosztów leczenia

Zarządzanie procedurami medycznymi

System kolejkowy

Zakłada się że w ramach rozbudowy części administracyjnej systemu szpitalnego zostaną

wdrożone następujące moduły systemu:

Finanse i księgowość

Koszty

Rejestr sprzedaży

Rejestr zakupów

Zamówienia zakupu oraz kontrakty

Zamówienie sprzedaży pozamedycznej, zamówienia cykliczne

Windykacja

Kasa

Łączna ilość

licencji

umożliwiająca

pracę w części

szarej to 70

użytkowników.

W chwili obecnej

Szpital posiada 64

aktywne konta (z

wyłączeniem

portalów

samoobsługowych

Strona 32 z 204

Gospodarka Magazynowa

Środki trwałe

Wyposażenie

Kadry

Płace

Grafiki (open)

Kalkulacja Kosztów Leczenia

Wycena Procedur Medycznych

Budżetowanie

Raportowanie AOTMiT

Portal pracowniczy

Zamówienia publiczne

Kalkulacja kosztów

o projektów, inwestycji

o kosztów leczenia na pacjenta

o innych nośników kosztowych nie ujętych rodzajowo

w planie kont (dodatkowe wymiary księgowe,

cechy)

– pracowniczych).

Dla portalu

samoobsługowego

pracowniczego

Zamawiający

oczekuje licencji

bez ograniczeń na

liczbę

użytkowników.

W chwili obecnej

szpital posiada

806 aktywnych

unikatowych kont

użytkowników w

systemach

informatycznych

części białej i

szarej.

Zamawiający dopuszcza, aby poszczególne funkcjonalności mogły być realizowane przez moduły o innych

nazwach. Oferowane produkty w ramach zintegrowanego rozwiązania muszą posiadać i realizować co

najmniej funkcjonalności przedstawione w rozdziale Wymagania Szczegółowe.

6.4 DANE DO PRZENIESIENIA DO NOWEGO ZSI

Oferent zapewni właściwe wsparcie związane z przeniesieniem (migracją i konwersją danych) we własnym

zakresie. Wsparcie o którym mowa będzie polegać na pobraniu, przygotowaniu (konwersji), kontroli

spójności i poprawności danych, a następnie importu do nowego wdrażanego rozwiązania i kontroli

końcowej poprawności.

Dobór środków technicznych koniecznych do wykonania tak opisanego zadania leży w całości po stronie

Oferenta.

6.4.1 HIS

W przypadku, gdy Oferent dokonuje rozbudowy systemu posiadanego przez Zamawiającego przy użyciu

produktu z innej linii produktowej (rozumianej jako produkt o innej nazwie handlowej lub innym

zarejestrowanym znaku towarowym) lub w przypadku wymiany systemu na nowy, Oferent zobowiązany jest

do migracji danych do nowego systemu. Wówczas Zamawiający oczekuje migracji danych z użytkowanych

dotychczas systemów, które będą wymieniane do nowego systemu w zakresie umożliwiającym pełną

kontynuację pracy w nowym rozwiązaniu.

Oznacza to, że Zamawiający oczekuje, że wykonawca dokona migracji co najmniej: danych pacjentów,

pobytów i wizyt oraz danych słownikowych (w tym różnych karotek, list cech, kartotek produktów

medycznych, danych kartotekowych, kontraktów, stanów magazynowych). Niemniej ostateczny i

Strona 33 z 204

szczegółowy zakres danych do przeniesienia zostanie określony na etapie analizy przedwdrożeniowej przy

czym zakłada się, że migracji podlegać będą wszystkie dane, które dostępne są w obecnych systemach.

6.4.2 ERP

Zamawiający oczekuje, że Oferent przygotuje i skonwertuje dane podstawowe w tym co najmniej kartoteki:

- Dostawców,

- Odbiorców, Płatników,

- Pracowników,

- Indeksów magazynowych,

- Produktów i usług,

- Środków trwałych,

- Kas, banków,

- Oraz wszystkie inne konieczne do prawidłowego uruchomienia systemu i zachowania ciągłości pracy.

Zakres konwersji danych ma zapewniać ciągłość pracy Zamawiającego w nowym systemie bez konieczności

odwoływania się (poszukiwania, pobierania, przenoszenia) danych pomiędzy starymi oraz nowym systemem ZSI

w okresie co najmniej rok wstecz od momentu uruchomienia systemu.

Zamawiający oczekuje, że Oferent przygotuje i skonwertuje dane bilansów otwarcia oraz transakcje z roku bieżącego

do dnia uruchomienia systemu, a w tym:

- Bilans otwarcia dla roku w którym nastąpi uruchomienie systemu,

- Otwarte transakcje należności na dzień uruchomienia,

- Otwarte transakcje zobowiązań na dzień uruchomienia,

- Nierozliczone salda innych kont bilansowych na dzień uruchomienia,

- Minimum salda poszczególnych miesięcy za okres od początku roku do dnia uruchomienia systemu, tak aby

możliwe było wykonanie kompletnego i poprawnego „bilansu próbnego” za dowolny okres narastająco w roku

uruchomienia systemu.

- Danych kadrowych oraz płacowych na dzień uruchomienia oraz za poprzednie lata, koniecznych do

zachowania ciągłości rozliczeń bez konieczności odwoływania się do danych z innego źródła lub

wprowadzania ich ręcznie;jak także na potrzeby prowadzenia sprawozdawczości wewnętrznej oraz

zewnętrznej,

- Grafików i harmonogramów pracy na dzień uruchomienia tak aby zapewnić ciągłość rozliczeń kadrowo-

płacowych oraz wymagań raportowych.

Zamawiający oczekuje, że konwersja bilansów otwarcia obejmie zakres minimalnie taki, aby zapewnił ciągłość pracy

oraz raportowania z wdrożonego ZSI.

6.4.3 Integracja z urządzeniami

W zakresie części HIS oraz ERP Zamawiający oczekuje integracji z wdrażanym rozwiązaniem urządzeń m.in. z

aparatami EKG, KTG, Tomografem komputerowym, angiografem, aparatami RTG, kasami fiskalnymi i innymi

6.4.4 Warunki przeniesienia danych

Zamawiający informuje, że nie posiada dokumentacji struktur baz danych posiadanych systemów. Na prośbę

Oferenta, na podstawie art. 9a ust. 2 ustawy Pzp, Zamawiający umożliwi Oferenta dostęp do baz danych

posiadanych systemów informatycznych (wizja lokalna) i udzieli wsparcia Oferenta w dokonaniu

przeniesienia danych poprzez: nadanie wskazanym pracownikom Oferenta niezbędnych uprawnień do pracy

w systemie oraz do zapoznania się ze strukturami tabel w bazach danych posiadanych systemów. Dostęp do

baz danych posiadanych systemów informatycznych i ich dokumentacji, może być udzielony po uprzednim

uzgodnieniu terminu wizyty Oferenta i po uregulowaniu zasad dostępu do chronionych danych osobowych.

Strona 34 z 204

Zamawiający umożliwi Oferenta przeprowadzenie wizji lokalnej w dni robocze, pomiędzy godziną 9:00

a 14:00.

Zamawiający udostępni wykonawcy z którym podpisze umowę posiadane instrukcje obsługi zastępowanych

oraz integrowanych systemów jeśli takowe posiada lub jest w stanie bezpłatnie uzyskać.

Zakres przeniesienia danych zostanie określony przez Zamawiającego na wniosek Oferenta i ma odpowiadać

potrzebom Zamawiającego do kontynuacji świadczenia usług dla pacjentów i klientów w sposób

niezakłócony, tj. bez koniczności sięgania do danych zawartych w innych, już nie wykorzystywanych

systemach (nie pracujących produkcyjnie), jak też pozwalać na niezakłócone raportowanie i rozliczenia

Zamawiającego, tak zewnętrzne jak i wewnętrzne.

Jeśli przeniesienie danych i ich konwersja nie będzie możliwa w sposób automatyczny lub półautomatyczny,

Zamawiający oczekuje, że Oferent dokona przeniesienia danych w sposób ręczny, tj. przy pomocy swoich

zasobów osobowych i technicznych. Koszt takiego przeniesienia Oferent powinien ująć w ofercie.

Oferent ponosi odpowiedzialność za ewentualne szkody, wyrządzone przez jego pracowników, powstałe

w wyniku działań prowadzonych przez wykonawcę na bazach danych posiadanych systemów.

Informacje uzyskane przez Wykonawcę w toku wykonania czynności, o których mowa w art.75 ust.2 pkt 3

ustawy z dnia 4 lutego 1994 r. o Prawie autorskim i prawach pokrewnych (Dz.U.2019, poz.1231), stanowią

tajemnicę przedsiębiorstwa w rozumieniu Ustawy z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej

konkurencji (Dz.U.2019, poz.1010) i podlegają ochronie w niej przewidzianej.

7 SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

7.1 WYMAGANIA SZCZEGÓŁOWE

Zamawiający poniżej przedstawia wykaz oczekiwanych funkcji oprogramowania ZSI. Przedstawione

wymagania posegregowane są wg grup funkcjonalnych (modułów)tylko na potrzeby redakcyjne i nie

stanowią w żaden sposób wymagania samego w sobie (finalny podział na moduły, jeśli zachodzi, może być

inny).Przedstawione wymagania należy czytać w sposób ciągły i spójny, nie wskazują gdzie dana

funkcjonalność powinna być zlokalizowana, a jedynie w kontekście jakiego obszaru biznesu należy ją

rozpatrywać.

Wymagania wypisane w tym rozdziale należy traktować jako WYMAGANE (konieczne do realizacji).

Wymagania posiadające różne poziomy realizacji podlegają punktacji i ocenie.

7.1.1 Część biała HIS

7.1.1.1 Wymagania ogólne

Lp. Opis wymagania / punktacja

1. Działanie systemu System działa z poziomu popularnych (Chrome, FireFox, Edge) przeglądarek

internetowych i nie wymaga instalowania dodatków/wtyczek do przeglądarek

(Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System HIS działa z poziomu popularnych Chrome, FireFox, Edge) przeglądarek

internetowych ale wymaga instalowania dodatków/wtyczek do przeglądarek

(Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

Strona 35 z 204

System HIS działa z poziomu popularnych Chrome, FireFox, Edge) przeglądarek

internetowych

2. Monitoring kompletności

dokumentacji

System posiada aktywny monitoring kompletności dokumentacji lekarskiej i

pielęgniarskiej wraz z możliwością wylistowania brakujących dokumentów z

poszczególnych dni z poziomu widoku kontekstu pacjenta(Funkcjonalność

dodatkowa – wg pozacenowego kryterium oceny ofert)

System posiada aktywny monitoring kompletności dokumentacji lekarskiej i

pielęgniarskiej wraz z możliwością wylistowania brakujących dokumentów z

poszczególnych dni (Funkcjonalność dodatkowa – wg pozacenowego kryterium

oceny ofert)

System posiada aktywny monitoring kompletności dokumentacji lekarskiej i

pielęgniarskiej

3. System musi prezentować historię zmian dokumentów wraz z informacją o użytkowniku, który dokonał

modyfikacji dokumentu.

4. System musi prezentować podgląd danych pacjenta z różnych perspektyw (stan na dany dzień, podgląd

parametrów życiowych, wgląd w badania i wszystkie inne zdefiniowane przez użytkownika) w zakresie

wszystkich hospitalizacji pacjenta bez konieczności wychodzenia z kontekstu tego pacjenta.

5. W systemie musi znajdować się ciągły podgląd najważniejszych informacji z hospitalizacji pacjenta w trakcie

uzupełniania innych dokumentów tego pacjenta wraz z możliwością przenoszenia/kopiowania dowolnych

informacji do aktualnie wypełnianej dokumentacji i możliwość użycia tych danych w bieżącej pracy.

6. System musi posiadać wbudowane mechanizmy uzupełnienia dokumentacji w dowolnym momencie.

7. Uzupełnianie

dokumentów

System ma możliwość niezależnego uzupełniania dokumentów przez poszczególne

grupy personelu (lekarz, pielęgniarka, sekretarka) bez wzajemnej blokady

uzupełniania danego dokumentu oraz z możliwością podglądu wprowadzonej

informacji przez inną grupę (Funkcjonalność dodatkowa – wg pozacenowego

kryterium oceny ofert)

System nie ma możliwości niezależnego uzupełniania dokumentów przez

poszczególne grupy personelu (lekarz, pielęgniarka, sekretarka) bez wzajemnej

blokady uzupełniania danego dokumentu oraz z możliwością podglądu

wprowadzonej informacji przez inną grupę

8. System musi posiadać funkcjonalność zarządzania wydrukami (zarządzanie drukarkami, kolejkami,

konfiguracja, sprawdzanie poprawności działania drukarek, historia drukowanych dokumentów. W

szczególności system musi obsługiwać drukowanie różnych dokumentów na różnych, zdefiniowanych przez

użytkownika formatach papieru. Dopuszcza się zarządzanie drukarkami przez domenę Windows (AD)

9. System musi umożliwiać skanowanie dokumentów wraz z umieszczaniem ich w wybranym kontekście

(pacjent, badanie)

10. Obsługa formularzy System ma możliwość tworzenia i zapisu przez uprawnionych użytkowników bez

zaawansowanych kompetencji informatycznych całych dokumentów w postaci

formularzy do ponownego wykorzystania (Funkcjonalność dodatkowa – wg

pozacenowego kryterium oceny ofert)

Strona 36 z 204

System ma możliwości tworzenia i zapisu przez administratorów bez kompetencji

programistycznych systemu formularzy do ponownego wykorzystania

(Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

11. Prezentacja wyników

laboratoryjnych

System przedstawia interaktywne wykresy wyników laboratoryjnych prezentując

zmiany koloru ekranu dla wyników badań laboratoryjnych poza normą

(Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System przedstawia wyniki badań laboratoryjnych w normalnej postaci liczbowej

12. Wizualizacja System ma możliwość oznaczania kolorami poszczególnych pól ekranu w celu

zwrócenia uwagi na dane istotne z punktu widzenia organizacji pracy danej

komórki organizacyjnej (Funkcjonalność dodatkowa – wg pozacenowego

kryterium oceny ofert)

System nie ma możliwości oznaczania kolorami poszczególnych pól ekranu w celu

zwrócenia uwagi na dane istotne z punktu widzenia organizacji pracy danej

komórki organizacyjnej

13. System musi umożliwiać pracę wielu użytkowników jednocześnie w ramach jednej wizyty. Jeden użytkownik

może dodawać rozliczenie świadczenia drugi uzupełniać dane medyczne dla tej samej wizyty w jednym czasie

14. System musi pozwalać wprowadzić na jednej wizycie rozliczenia NFZ jak i komercyjne. Wszystkie operacje

dodawania rozliczeń wykonywane muszą być z jednego okna rozliczeniowego. Zaewidencjonowane dane

muszą się poprawnie sprawozdać do NFZ z wyłączeniem usług komercyjnych natomiast na dokumentach

rozliczeniowych typu paragon, faktura z danej wizyty powinny się podpowiadać tylko usługi komercyjne z

wyłączeniem pozycji powiązanych z kontraktem NFZ.

15. System z poziomu administracji musi umożliwiać definiowanie własnych adnotacji do dokumentów, które będą

widoczne dla użytkowników w trakcie ich uzupełniania

16. Zgłoszenia choroby

nowotworowej do

Rejestru Nowotworów

System umożliwia importowanie i eksportowania zgłoszenia choroby

nowotworowej do Rejestru Nowotworów (Funkcjonalność dodatkowa – wg

pozacenowego kryterium oceny ofert)

System nie umożliwia importowania i eksportowania zgłoszenia choroby

nowotworowej do Rejestru Nowotworów

17. Wymagana jest zgodność systemu z następującymi ustawami i rozporządzeniami:

- Ustawa o działalności leczniczej ;

- Ustawa o systemie informacji w ochronie zdrowia ;

- Ustawa o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych ;

- Rozporządzenie Ministra Zdrowia w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej

przetwarzania ;

- Rozporządzenie Ministra Zdrowia w sprawie zakresu niezbędnych informacji gromadzonych przez

świadczeniodawców, szczegółowego sposobu rejestrowania tych informacji oraz ich przekazywania podmiotom

zobowiązanym do finansowania świadczeń ze środków publicznych;

- Rozporządzenie Ministra Zdrowia w sprawie szczegółowego zakresu danych objętych wpisem do rejestru

podmiotów wykonujących działalność leczniczą oraz szczegółowego trybu postępowania w sprawach

dokonywania wpisów, zmian w rejestrze oraz wykreśleń z tego rejestru;

18. System musi być wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia muszą

Strona 37 z 204

funkcjonować na poziomie klienta (aplikacja) i serwera (serwer baz danych ),

19. System zapewnia odporność struktur danych (baz danych) na uszkodzenia oraz pozwala na szybkie odtworzenie

ich zawartości i właściwego stanu, jak również posiada łatwość wykonania ich kopii bieżących oraz łatwość

odtwarzania z kopii. System jest wyposażony w zabezpieczenia przed nieautoryzowanym dostępem.

20. W przypadku przechowywania haseł w bazie danych, hasła muszą być zapamiętane w postaci niejawnej

(zaszyfrowanej).

7.1.1.2 Wydajność

Lp. Opis wymagania / punktacja

1. System powinien umożliwiać jednoczesną pracę na dowolnej liczbie stanowisk nieograniczonej liczby

użytkowników niezależnie od funkcjonalności i modularności aplikacji, na Stacjach Roboczych pracujących

pod kontrolą systemu operacyjnego np. Microsoft Windows, w wersjach wspieranych przez producenta

systemu operacyjnego. Docelowo zakłada się jednoczesną pracę na maksymalnie 1 000 stanowiskach.

2. Maksymalny czas odpowiedzi Systemu w warunkach rzeczywistej pracy dla czynności potwierdzenia lub

wycofania edycji, wyszukiwania, wprowadzania, usuwania danych, z wyłączeniem zestawień statystycznych

i raportów, nie może być dłuższy niż 5 sekund dla 250 równocześnie pracujących użytkowników.

3. Maksymalny czas odpowiedzi Systemu w warunkach rzeczywistej pracy dla zadania wykonania zestawienia

statystycznego lub raportu nie może być dłuższy niż 15 minut przy 250 równocześnie pracujących

użytkownikach.

4. Oferent przedstawi zakres testów akceptacyjnych wydajnościowo - obciążeniowych dla opisanej infrastruktury

technicznej i oprogramowania, potwierdzających spełnienie parametrów odnośnie zadanych czasów

odpowiedzi Systemu. W przypadku jeśli opisana w specyfikacji infrastruktura jest niewystarczająca do

spełnienia zadanych wymagań wydajnościowych, Oferent zobowiązany jest do dostarczenia na własny koszt

dodatkowych serwerów i/lub macierzy.

5. Po skonfigurowaniu pełnej infrastruktury, Oferent przeprowadzi w obecności Zamawiającego testy wydajności

Systemu i w przypadku nie spełnienia wymagań powinien rozbudować System (licencyjnie, programowo,

sprzętowo) lub zmodyfikować sposób przetwarzania danych, zapewniając tym samym spełnienie wymagań bez

dodatkowych kosztów dla Zamawiającego.

7.1.1.3 Uprawnienia

Lp. Opis wymagania / punktacja

1. Przed przystąpieniem do wdrożenia Oferent musi przedstawić oświadczenie, o fakcie niewykorzystywania

udostępnionych mu danych w celu innym jak tylko do wykonania wdrożenia i działań związanych z

utrzymaniem i serwisowaniem Systemu.

2. System musi posiadać zaimplementowane mechanizmy pozwalające na ograniczenie dostępu do danych i

funkcji Systemu dla osób niepowołanych.

3. System musi zapewniać automatyczne wylogowanie użytkownika i wymuszać ponowną autoryzację po

określonym, definiowalnym czasie bezczynności.

Strona 38 z 204

4. System musi zapewniać możliwość określenia maksymalnej ilości nieudanych prób logowania, po których

nastąpi automatyczne wyłączenie aplikacji oraz maksymalnej ilości błędnych prób logowania, po których

nastąpi blokada konta użytkownika.

5. System musi zapewniać możliwość określenia uprawnień odnośnie zasad modyfikacji zapisów dotyczących

zdarzeń terapeutycznych, dostępu do historii poprzednich zapisów, możliwości chronologicznego

wyszukiwania, przeglądania i drukowania tych zapisów (w tym dokumentacji medycznej).

6. System musi zapewniać dostęp z poziomu interfejsu użytkownika do danych historycznych, wpisów odnośnie

indywidualnej dokumentacji medycznej oraz danych personalnych pacjenta, stosownie do nadanych uprawnień.

7. Podstawowe funkcjonalności lub moduły tj. gabinet, pracownia muszą być dostępne w ramach profilu danego

użytkownika w ramach posiadanych przez niego uprawnień po jednokrotnym zalogowaniu (system nie może

wymagać oddzielnego logowania do każdej funkcjonalności lub modułu).

8. System musi zapewniać możliwość tworzenia grup użytkowników charakteryzujących się wybranym zestawem

uprawnień. Nadawanie uprawnień użytkownikowi następuje poprzez przypisanie go do grupy.

9. System musi zapewniać możliwość definiowania, edycji, anulowania przez administratora z poziomu interfejsu

użytkownika praw dostępu dla poszczególnych grup użytkowników do określonych: modułów, funkcji,

jednostek organizacyjnych, opcji menu, formularzy, przycisków, raportów, wydruków i urządzeń. Funkcje, w

tym elementy graficznego interfejsu użytkownika, do których dostęp został zabroniony powinny być

niedostępne.

10. Kopiowanie praw dostępu między

użytkownikami.

System zapewnia możliwość kopiowania praw dostępu między

użytkownikami (Funkcjonalność dodatkowa – wg

pozacenowego kryterium oceny ofert)

System nie zapewnia możliwości kopiowania praw dostępu

między użytkownikami

11. System musi zapewniać możliwość tworzenia wzorców praw dostępu i definiowania na ich podstawie grup

uprawnień.

12. System powinien zapewniać możliwość określania parametrów hasła: długość, czas obowiązywania, wymagana

kombinacja znaków

13. System powinien zapewniać możliwość walidacji nadawanych haseł zgodnie z wymogami prawa, w tym nie

powinien dopuszczać możliwości nadania takiego samego w zadanym przedziale czasowym.

14. System powinien zapewniać czytelną prezentację nadanych użytkownikom uprawnień, przedstawiającą do

jakich jednostek, modułów, funkcji, szablonów dokumentów dany użytkownik ma dostęp oraz jakie

uprawnienia posiada w tym zakresie.

15. System powinien zapewniać możliwość zmiany hasła przez zalogowanego użytkownika.

16. System powinien zapewniać możliwość ograniczenia dostępu do wizyt pacjenta dla komórek z zakresu

psychologii/psychiatrii przez personel nie pracujący w tych komórkach, w tym powinien zapewniać możliwość

ograniczenia uprawnień do podglądu historii choroby pacjentów tylko przez personel medyczny ich

prowadzący.

17. System powinien być zabezpieczony przed nieautoryzowanym dostępem zarówno na poziomie serwera bazy

danych jak i na poziomie oprogramowania aplikacyjnego.

18. System powinien zapewniać przechowywanie haseł w bazie danych w postaci niejawnej (zaszyfrowanej).

Strona 39 z 204

19. System powinien zapewniać możliwość zabezpieczenia dostępu do aplikacji zgodnie z obowiązującymi

przepisami w tym poprzez logowanie użytkowników z wykorzystaniem loginu i hasła.

7.1.1.4 Gromadzenie danych w systemie

Lp. Opis wymagania / punktacja

1. Rejestr pacjentów System ma jeden centralny rejestr pacjentów (Funkcjonalność

dodatkowa – wg pozacenowego kryterium oceny ofert)

System opiera się o więcej niż jeden rejestr pacjentów, które są

wzajemnie zintegrowane

2. System musi zapewniać jednokrotne wprowadzenie danych, np. danych osobowych danego pacjenta

3. System musi zapewniać dostępne dla uprawnionego użytkownika z poziomu interfejsu uprawnionego

użytkownika mechanizmy umożliwiające usunięcie lub scalenie podwójnych wpisów np. dotyczących danych

osobowych pacjenta, powstałych na skutek błędnego wprowadzenia przez operatora określonych

identyfikatorów lub innych danych elementarnych (z uwzględnieniem np. deklaracji POZ, wizyt itp.).

4. System musi zapewniać możliwość wprowadzenia i ewidencji wszystkich, wymaganych prawem, danych

dotyczących pacjenta i opiekuna prawnego, w szczególności: nr PESEL, nr dokumentu ubezpieczenia, danych

adresowych i kontaktowych, pokrewieństwa oraz zapewnia wykazanie tych danych w informacjach

o sprawozdawanych świadczeniach.

5. System musi umożliwiać zdefiniowanie zablokowania zarejestrowania więcej niż jednego pacjenta np. o tym

samym numerze pesel lub o tym samym imieniu nazwisku i dacie urodzenia.

6. System musi zapewniać pełne i zgodne z obowiązującymi wymogami i prawem ewidencjonowanie danych w

zakresie danych pacjentów i realizowanych świadczeń, w tym odnośnie pacjentów obcokrajowców (w tym

pacjentów z Unii Europejskiej, na rzecz których realizowane są świadczenia na podstawie przepisów

o koordynacji) i posiadających indywidualne ubezpieczenie zdrowotne, a także musi zapewniać możliwość

rozliczenia świadczeń wykonanych na rzecz tych pacjentów z kontrahentami (w szczególności z NFZ).

7. System musi zapewniać możliwość gromadzenia informacji powiązanych z leczeniem pacjenta w ramach

DiLO.

8. System musi zapewniać możliwość gromadzenia informacji w postaci plików typu PDF, JPEG, TXT

dołączanych do wybranych zakresów danych (dane pacjenta, dane wizyty, dane badania), w tym badań

diagnostycznych obrazowych wykonanych poza Przychodnią i zeskanowanych wersji papierowej dokumentacji

medycznej (np. z innych placówek medycznych).

9. System musi dopuszczać wprowadzenie rozpoznania według lekarza zlecającego w formie słownikowej

i opisowej.

10. System musi umożliwiać wprowadzenie komentarza odnośnie danych osobowych pacjenta oraz świadczenia, w

tym w trakcie rejestracji pacjenta, widocznego zarówno dla pracownika rejestracji po wyszukaniu odpowiednio

pacjentów lub świadczeń danego pacjenta, jak również dla pracownika wykonującego świadczenie.

11. System musi zapewniać możliwość definiowania dla jednostek organizacyjnych i personelu własnych

podręcznych (preferowanych) zestawów rozpoznań, realizowanych procedur, zleceń itp. na bazie słowników

ogólnych.

Strona 40 z 204

12. System musi zapewniać ewidencjonowanie przyporządkowania do wykonanego świadczenia medycznego

informacji o ilości i typie zużytych materiałów i leków

13. System musi zapewniać możliwość tworzenia oraz wykorzystania szablonów dla wyników opisowych.

14. System musi zapewniać możliwość wprowadzenia blokady edycji wpisów dotyczących zaewidencjonowanych

świadczeń w zadanym przedziale czasowym (od miesiąca do miesiąca) dla określonych opcjonalnie: komórek

organizacyjnych, personelu realizującego, umów, świadczeń (produktów kontraktowych).

15. System musi zapewniać możliwość wyszukiwania danych (np. danych osobowych pacjentów)

i przeszukiwania słowników po początkowym ciągu znaków lub opcjonalnie po ciągu znaków wewnątrz

wyszukiwanej pozycji.

16. System musi umożliwiać pracownikom szybkie wprowadzanie danych rozliczeniowych (kod produktu

kontraktowego, kod produktu jednostkowego, rozpoznania, zrealizowane procedury medyczne) dotyczących

świadczeń wykonanych w gabinetach (wprowadzenie danych z listy dziennej przyjęć danego lekarza poprzez

np. wsadowy import wskazanych wartości z arkusza xls lub wprowadzenie tych danych z wykorzystaniem

jednej formatki umożliwiającej szybkie uzupełnienie danych dla danego dnia i lekarza).

17. System musi umożliwiać stosowanie podpisu cyfrowego kwalifikowanego i niekwalifikowanego, zgodnie

z obowiązującymi wymogami prawa.

7.1.1.5 Obsługa załączników

Lp. Opis wymagania / punktacja

1. System musi posiadać funkcjonalność dołączania załączników do dokumentacji medycznej Pacjenta (do

zlecenia, do badania, do opisu, do pobytu pacjenta np. oświadczenia) z poziomu pracy danego użytkownika np.

rejestracja, poradnia, oddział.

2. System musi posiadać funkcjonalność ewidencji i kontroli składanych papierowych oświadczeń przez pacjenta:

lista kontrolna, skany oświadczeń, dane identyfikacyjne w tym nadany numer, miejsce archiwizacji.

3. System musi posiadać funkcjonalność dołączania załączników w kontekście danych Pacjenta.

4. System musi posiadać funkcjonalność przeglądania załączników dołączonych do dokumentacji medycznej.

5. Obsługa

załączników

System posiada funkcjonalność dołączania załączników do dokumentacji Pacjenta

bezpośrednio z urządzenia skanującego oraz ze skazanego zasobu sieciowego

(Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System posiada funkcjonalność dołączania załączników do dokumentacji Pacjenta ze

skazanego zasobu sieciowego

6. System musiumożliwiać podgląd z poziomu gabinetów załączników dodanych w historii choroby pacjenta.

7. System musiumożliwiać zdefiniowanie na poziomie administratora maksymalnej wielkości plików dodawanych

jako załączniki w zakresie od 1 do 20 MB.

7.1.1.6 Dokumentacja medyczna

Lp. Opis wymagania

1. System musiumożliwiać wyświetlanie pełnej dokumentacji poszczególnych pacjentów

Strona 41 z 204

2. System musi umożliwiać weryfikację podpisu elektronicznego niekwalifikowanego na podpisanych wizytach

3. System musi umożliwiać weryfikację podpisu elektronicznego kwalifikowanego na podpisanych wizytach

4. System musi umożliwiać zbiorcze drukowanie historii choroby wybranego pacjenta

5. System musi umożliwiać podgląd dokumentacji medycznej (pojedyncze wizyty)

7.1.1.7 Izba przyjęć

Wymagania dla modułów obsługi szpitala w zakresie lecznictwa stacjonarnego i otwartego

Lp. Opis wymagania

1)

Przyjęcie nowego pacjenta i wprowadzenie danych personalnych:

- Imię, Nazwisko, PESEL (system weryfikuje poprawność numeru PESEL, dekoduje datę urodzenia i płeć)

automatyczne wypełnienie daty urodzenia i płci, typ i nr dokumentu tożsamości, obywatelstwo, grupa krwi,

choroba zakaźna, miejsce urodzenia, możliwość wprowadzenia uwag

- Adres zameldowania: kod pocztowy (po wprowadzeniu kodu pocztowego automatyczne uzupełnienie

miejscowości z zawężeniem przypisanych do kodu ulic, automatyczne uzupełnienie województwa i kraju), nr

domu, nr lokalu

- Adres zamieszkania i adres korespondencyjny - możliwość skopiowania z adresu zameldowania

- Kontakt telefoniczny i adres email

2) Dane pacjenta: oddział NFZ, uprawnienia pacjenta, nr pacjenta w kartotece

3) Opiekunowie - możliwość dodania kilku z odnotowania danych: Imię, Nazwisko, Pesel, Telefon, adres

zamieszkania. Możliwość odnotowania, że pacjent jest ubezwłasnowolniony lub niezdolny do świadomego

wyrażania zgody, wówczas dane dotyczące opiekunów są wymagane do uzupełnienia

4) Zarejestrowanie jakie stałe leki przyjmuje pacjent z użyciem słownika leków, a jeśli danego leku nie byłoby w

słowników, wówczas w polu notatek

5) Możliwość ewidencji specyficznych danych dotyczących pacjentów z krajów Unii Europejskiej przyjmowanych w

ramach przepisów o koordynacji.

6) Możliwość rejestracji danych pacjenta przyjmowanego na podstawie decyzji wydanej przez wójta/burmistrza.

7) Możliwość wprowadzenia informacji o trybie przyjęcia i o wyrażeniu zgody pacjenta na leczenie.

8) W przypadku braku zgody pacjenta na leczenie możliwość ewidencji podstawy przymusowego przyjęcia.

9) Rejestracja pobytu pacjenta w Izbie Przyjęć:

10) Wprowadzenie danych o rozpoznaniu z wykorzystaniem słownikaICD10,

11) Wprowadzenie danych zeskierowania,

12) Wprowadzenie danychpłatnika.

13) Wpisanie wywiadu wstępnego z możliwością użycia słownika,

Strona 42 z 204

14) Wpisanie wywiadu przedporodowego.

15) Możliwość określenia czy świadczenie jest świadczeniem ratującym zdrowie lub życie pacjenta.

16) Możliwość ewidencji godziny przyjęcia pacjenta oraz godziny zakończenia obsługi.

17) Moduł umożliwia blokadę dokonania ponownego przyjęcia pacjenta przebywającego już w szpitalu.

18) Moduł umożliwia zdefiniowanie czy i dla jakich oddziałów dostępne jest dokonanie ponownego przyjęcia pacjenta

przebywającego już w szpitalu.

19) Prowadzenie rejestru (skorowidza) pacjenta z możliwością przeglądu danych archiwalnych z poszczególnych

pobytów w szpitalu (rejestr pobytów)

20) Możliwość informowania zaraz przy przyjęciu pacjenta w izbie Przyjęć o stwierdzanym wcześniej nosicielstwie

patogenu alarmowego/czynnym zakażeniu patogenem alarmowym w celu wprowadzenia wczesnej izolacji

21) Możliwość wyszukiwania pacjentów wg różnych parametrów

22) Możliwość przyjęcia pacjenta NN.

23) Scalenie danych pobytu pacjenta w przypadku braku możliwości pierwotnego zweryfikowania jego danych

z poprzednimi pobytami po potwierdzeniu danych osobowych np. pacjenta NN

24) Rejestracja pobytu pacjenta na Izbie Przyjęć - odnotowanie danych przyjęciowych (dane o rozpoznaniu, danych ze

skierowania, płatniku, itp.)

25) Weryfikacja pacjenta w systemie e-WUŚ i archiwizacja kolejnych wpisów. Możliwość wydruku oświadczeń

o ubezpieczeniu

26) Blokowanie możliwości dokonanie ponownego przyjęcie pacjenta przebywającego już w szpitalu

27) Możliwość ewidencjonowania i wydruk oświadczeń pacjenta/opiekuna prawnego potwierdzających

uprawnienie do świadczeń opieki zdrowotnej finansowanych ze środków publicznych

28) Odnotowanie wykonanych pacjentowi procedur

29) Możliwość wystawiania recept elektronicznych oraz wydruku recept z systemu dla chorych nie wymagających

hospitalizacji

30) Wywiad i badanie przedmiotowe (z podpowiedziami), możliwość kopiowania z poprzednich hospitalizacji,

poradni, izby przyjęć (i odwrotnie), obserwacje i in.

31) Opcja wypisywania druków, zaświadczeń, skierowań, zwolnień z pracy; możliwość podglądu druków

wypisywanych poprzednio (zarówno z oddziału jak i poradni) z możliwością powielania, kopiowania itd.

32) Ewidencja produktów zgodnie z NFZ.

33) Ewidencja zużytych środków farmaceutycznych i innych środków dostępnych w apteczce jednostki.

34) Blokowanie zamknięcia wizyty pacjenta w przypadku braku Karty Zgłoszenia Choroby

Psychicznej/Nowotworowej/ Zakaźnej, jeśli pacjentowi zaewidencjonowano takowe rozpoznanie.

35) Możliwość definiowania przez administratora minimalnego zbioru danych, który musi być uzupełniony przed

zamknięciem wizyty pacjenta.

Strona 43 z 204

36)

Rejestracja opuszczenia Izby Przyjęć przez pacjenta w jednym z trybów:

- Odmowa przyjęcia do szpitala – wpis do Księgi Odmów i PoradAmbulatoryjnych;

- Zaplanowanie późniejszego terminu przyjęcia i odnotowanie skierowania pacjentado kolejki oczekujących –

wpis do Księgi Oczekujących;

- Skierowanie na oddział (ustalenie trybu przyjęcia, oddziału) – wpis do KsięgiGłównej;

- Odnotowanie zgonu pacjenta w Izbie Przyjęć – wpis do KsięgiZgonów;

- Udzielenie pomocy doraźnej– wpis do Księgi Odmów i PoradAmbulatoryjnych.

37)

Prowadzenie analizy odmów hospitalizacji będzie prowadzona w oparciu o ustalony katalog. Katalog będzie

dostępny dla lekarza z poziomu porady/odmowy. Zarejestrowana przyczyna odmowy będzie widoczna w Księdze

Porad i Odmów Ambulatoryjnych.

38) Obsługa kart diagnostyki i leczenia onkologicznego (DiLO)

39) Możliwość przyjęcia pacjenta na podstawie kartyDiLO,

40) Weryfikacja zgodności danych oraz kompletu danych niezbędnych do przyjęcia pacjentana podstawie karty DiLO,

w tym tryb przyjęcia, numer karty, etap realizacji karty,

41) Możliwość założenia karty DiLO w trakcie trwaniaświadczenia,

42) MożliwośćzałożeniakolejnejkartyDiLOpacjentadladrugiejgrupyrozpoznańbez konieczności zamykania aktywnej

karty,

43) Możliwość zablokowania zakładania kilku aktywnych kart DiLO dlapacjenta,

44) Możliwość wydruku karty DiLO w wybranym trybie: tylko strony dot. Obsługiwanegoetapu karty, wszystkie

strony, objaśnienia,

45) Możliwość realizacji kilku etapów karty DiLO podczas jednegoświadczenia,

46) Możliwość zamknięcia karty DiLO podczas realizacjiświadczenia,

47) Możliwość anulowania wprowadzonej kartyDiLO,

48) MożliwośćusunięciainformacjiorealizacjietapukartyDiLOwramachświadczeniabez konieczności usuwania całej

karty,

49) Podglądlistyświadczeń,wramachktórychnastępujerealizacjakolejnychetapówobsługi karty DiLO.

50) Odmowa przyjęcia do szpitala - wpis do Księgi Odmów i lub Porad Ambulatoryjnych

51)

Prowadzenie analizy odmów hospitalizacji będzie prowadzona w oparciu o ustalony katalog. Katalog będzie

dostępny dla lekarza z poziomu porady/odmowy. Zarejestrowana przyczyna odmowy będzie widoczna w Księdze

Porad i Odmów Ambulatoryjnych.

52) Możliwość wystawienia skierowania do innego Szpitala z Izby Przyjęć

53) Możliwość wystawienia karty informacyjnej z przyczyną odmowy przyjęcia do szpitala wystawianej w Izbie

Przyjęć

54) Odnotowanie skierowania pacjenta do kolejki oczekujących – wpis do Księgi oczekujących

Strona 44 z 204

55) Generowanie wymaganych przez NFZ raportów z kolejki oczekujących

56) Możliwość wprowadzenia informacji o rodzaju leczenia, na które pacjent oczekuje

57) Skierowanie/cofnięcie skierowania na oddział (ustalenie trybu przyjęcia, form płatności, wydruk pierwszej strony

historii choroby

58) Odnotowanie zgonu pacjenta na Izbie Przyjęć, wpis do Księgi Zgonów

59) Przegląd ksiąg: Księga Główna, Oczekujących, Odmów i Porad Ambulatoryjnych, Zgonów

60) Wydruk danych z poszczególnych ksiąg

61) Możliwość sprawdzenia stanu wolnych łóżek na poszczególnych oddziałach

62) Wydruk pierwszej strony historii choroby nowo przyjętego pacjenta wg różnych, zdefiniowanych na etapie

wdrożenia wzorów historii choroby

63) Możliwość wydruku podstawowych dokumentów (np. karta informacyjna izby przyjęć, karta odmowy przyjęcia

do szpitala, przyjęcie ambulatoryjne itp.) z zakresu danych gromadzonych w systemie

64) Możliwość przeglądu danych archiwalnych o pacjentach przebywających w przeszłości na Izbie Przyjęć

65) Odczyt kodu kreskowego z opaski pacjenta

66) Możliwość parametryzacji pól obligatoryjnych przy przyjęciu pacjenta do szpitala

67) Weryfikacji e-WUŚ (weryfikacja indywidualna i zbiorcza)

68) Wydruk opasek dla pacjenta z kodem kreskowym

69) Nadruk danych pacjenta na wzór Historii choroby oraz na medyczna kartę pacjenta (wzory dokumentów

obowiązujących w Szpitalu)

70) Współpraca z czytnikami kodów kreskowych, w zakresie co najmniej identyfikacji pacjenta po kodzie

zamieszczonym na dokumentacji medycznej oraz pracownika po identyfikatorze osobowym.

71) Współpraca z czytnikami dowodów osobistych w zakresie co najmniej odczytywania danych pacjenta: nazwisko,

imię, PESEL, nr dowodu osobistego

72)

Moduł umożliwia generowanie zestawień:

1. wizytywIzbiePrzyjęć(zestawieniewszystkichwizytwdanymokresiewgdecyzjidot. procesu leczenia),

2. zestawienie wykonania produktów NFZ dotyczących danejwizyty,

3. zestawienie rozpoznańokreślonychupacjentów(zestawienie zarówno konkretnych rozpoznań jak i dla

wszystkich wg płatnika, województwa, okresu), zestawienie bieżących przyjęć w IzbiePrzyjęć.

7.1.1.8 SOR

Lp. Opis wymagania

1) System musi umożliwiać podział SOR na obszary i przypisania pacjenta do określonego obszaru SOR. Podział

SOR na obszary jest opcjonalny.

Strona 45 z 204

2) System musi umożliwiać dla jednostek organizacyjnych typu SOR włączenie obsługi i prezentacji statusu pilności

(TRIAGE) pacjentów.

3) System musi umożliwiać przypisanie lub zmianę statusu pilności (TRIAGE) pacjenta w dowolnym momencie

pobytu na SOR.

4) Oznaczanie statusu pilności (TRIAGE) (jeśli jest włączone) pacjenta powinno być wymagane i status ten powinien

być wyraźnie prezentowany na liście pacjentów oraz danych pobytu pacjenta na SOR. Wystarczającym sposobem

prezentacji statusu pilności pacjenta jest użycie odpowiadającemu danemu statusowi koloru.

5) Przypisanie i zmiana statusu pilności pacjenta musi być zapisanie w dzienniku systemu z podaniem przyczyny

zmiany.

6) System musi wymagać autoryzacji zmiany statusu pilności.

7) Na panelu głównym pulpitu SOR, oraz na liście pacjentów system musiprezentować liczbę pacjentów SOR w

podziale na statusy pilności (TRAGE). Przypisanie i zmiana statusu pilności powinna wymusić aktualizację

statystyk liczb pacjentów w podziale na statusy.

8) System musiumożliwiać klasyfikację pacjentów z wykorzystaniem następujących kolorów: czarny, czerwony,

pomarańczowy, żółty, zielony, niebieski

9) Przypisanie i zmiana statusu pilności powinna wymusić aktualizację statystyk liczb pacjentów w podziale na

statusy.

10) Dla jednostki organizacyjnej typu SOR musi być możliwość zdefiniowania standardów czasowych obsługi

pacjenta dla poszczególnych kolorów (kolory TRIAGE).

11) Na panelu głównym pulpitu SOR oraz na liście pacjentów SOR system musi prezentować czas oczekiwania

liczony na podstawie czasów obsługi przypisanych do poszczególnych kolorów.

12) System musi umożliwiać przeniesienie w trybie nagłym na oddział, nie wymagające uprzedniego uzupełnienia

danych pobytu na SOR.

13)

System musi udostępnić funkcjonalność szybkiego skierowania pacjenta na oddział nawet

w sytuacji, gdy nie wypełniono w systemie wszystkich danych (w tym wymaganych do zakończenia pobytu na

SOR), danych i dokumentów dokumentacji medycznej, wymaganej autoryzacji danych.

14) Pacjenci przeniesieni na oddział w trybie pilnym muszą być oznaczeni na liście pacjentów SOR.

15)

Dane pacjentów przeniesionych w trybie pilnym do innej jednostki organizacyjnej mogą być uzupełnione w

dowolnym momencie, ale nie uzupełnienie przez SOR wymaganych danych powinno blokować wypis lub

przeniesienie pacjenta z jednostki, do której został w trybie pilnym skierowany.

16) Musi istnieć możliwość wskazania lekarza prowadzącego.

17) System musi wspierać tworzenie wymaganej dla SOR dokumentacji medycznej.

18) System musiumożliwiać wyświetlanie listy pacjentów przebywających na SOR w zadanym przedziale czasu,

których status potwierdzenia płatnika jest ustawiony na "Oświadczenie".

19) System musiumożliwiać rozliczenie komercyjne pacjentów nieuprawnionych do świadczeń. Wymaganie będzie

realizowane w ramach rozliczeń komercyjnych lecznictwa zamkniętego.

20) Zaawansowane wyszukiwanie pacjenta.

Strona 46 z 204

21)

System musi udostępniać zaawansowane metody wyszukiwania pacjentów z uwzględnieniem przeszukiwania pól

opisujących pacjentów NN oraz możliwości wpisania części i/lub wariantów ciągów znaków opisujących

nazwisko, imię, nazwisko rodowe, miejscowość zamieszkania, opis pacjenta NN. Użytkownik musi móc

zdecydować w momencie wyszukiwania czy wybiera zaawansowane metody wyszukiwania.

22) System musiumożliwiać przeszukiwanie również poprzednich wersji danych osobowych oraz danych pacjentów

scalonych z innymi pacjentami.

23)

System powinien umożliwiać śledzenie procesu udzielania świadczeń w przebiegu TRIAGE poprzez przypisanie

zadań wykonywanych przez personel za pomocą indywidualnych dla danej grupy kolorów informujących o

zleconych, wykonanych i zatwierdzonych zadaniach.

24)

System umożliwia integrację z aparaturą medyczną - analizatorem badań krytycznych, np. ekg, ktg w zakresie

możliwości podglądu i rejestracji wyników badań z tych urządzeń np. poprzez wywołanie obrazu z PACS poprzez

link.

25)

System w zależności od uzyskanych wyników badań automatycznie będzie przypisywał kolor TRIAGE.

Przypisany przez system kolor personel medyczny będzie uprawniony zmodyfikować w zależności od nadanych

uprawnień. (lekarz, pielęgniarka, ratownik medyczny).

26) System zapewni wyświetlanie komunikatów i alertów dot. m.in. o statusie zleconych badań diagnostycznych,

wyników alarmowych.

27) System zapewni implementację wyników badań diagnostycznych do HIS do dokumentacji medycznej pacjenta.

28)

System zapewni możliwość generowania raportów: liczba przyjętych, ICD, urazy wielonarządowe, przyjęcia w

tym obcokrajowcy i obywatele UE, zakres udzielonych świadczeń ze wskazaniem lekarza prowadzącego,

pacjentów przyjętych pod wpływem alkoholu i po zażyciu narkotyków, dopalaczy.

29) System powinien zliczać samodzielnie wybrane skale –SOFA (Sequential Organ failureAssesment), GCS

(Glasgow ComaScale) oraz umożliwiać podgląd kategoryzacji pacjentów w systemie rozliczeniowym NFZ

30) Możliwość przeglądu danych archiwalnych o pacjentach przebywających w przeszłości na Izbie Przyjęć z

uwzględnieniem ponownego powrotu pacjentów, którym odmówiono przyjęcia do Szpitala.

31)

System musi umożliwiać podgląd wyników badań laboratoryjnych, obrazowych, histopatologicznych i innych

wykonanych w przeszłości w Szpitalu u danego chorego o ile są dostępne w systemie (wg danych chorego, dat

hospitalizacji/badań).

32) W wypadku zatrzymania krążenia i resuscytacji – implementacja danych do modułu zdarzeń niepożądanych

33) System musi umożliwiać tworzenie i wydruk dokumentacji indywidualnej pacjentów SOR.

34) System musi umożliwiać obsługę dokumentacji zbiorczej.

35) System musi umożliwiać definiowanie własnych wykazów w oparciu o zgromadzone w systemie dane.

36) W module funkcjonuje Apteczka Oddziałowa ewidencja zużytych leków i materiałów oraz aktualizacja stanów

magazynowych.

37) Możliwość prowadzenia księgi transfuzji (zgodnie z rozporządzeniem o leczeniu krwią).

38) Możliwość zamawiania składników krwi (zgodnie z rozporządzeniem o leczeniu krwią).

39) Obsługa zgłaszania zdarzeń niepożądanych (zgodnie z rozporządzeniem o leczeniu krwią) z poziomu modułu

Strona 47 z 204

zdarzeń niepożądanych.

7.1.1.9 Obsługa oddziału

Lp. Opis wymagania / punktacja

1.

System musi zapewniać możliwość wyszukiwania pacjentów na liście oddziału bez użycia znaków

specjalnych co najmniej w zakresie:

1. Imię

2. Nazwisko

3. PESEL

4. Numer księgi głównej

5. Numer księgi oddziałowej

6. Lekarz prowadzący

7. Rozpoznanie

8. ID pacjenta

2

System musi zapewniać możliwość filtrowania listy pacjentów oddziału co najmniej według poniższych

kryteriów:

- Pacjenci bieżący, wypisani, zaplanowani

- Pacjenci bez lekarza prowadzącego

- Strefa

- Lekarz prowadzący

- Sala

3 Wyszukiwanie pacjentów System zapewnia możliwość zapisania szablonów filtrów wyszukiwania listy

pacjentów oddziału (Funkcjonalność dodatkowa – wg pozacenowego kryterium

oceny ofert)

System zapewnia wyszukiwanie listy pacjentów bez zapisania szablony filtrów

wyszukiwania

- 4

System musi zapewniać możliwość wyświetlania istotnych informacji o pacjencie na liście oddziału

przypisanych do profilu użytkownika co najmniej w zakresie:

- Data i godzina przyjęcia

- Lekarz prowadzący

- Sala i łóżko

- Rozpoznanie (pełne, kod, opis)

- 5

System ostrzeżeń System zapewnia możliwość wyświetlania ostrzeżeń na liście pacjentów oddziału co

najmniej w zakresie:

- Skala Norton, REAL, TORRANCE΄A.

- Ocena stanu odżywienia

- Liczba dni od założenia aktualnego cewnika

- Liczba dni cewnikowania

- Odleżyny

- Liczba dni od zakończenia poprzedniej hospitalizacji na oddziale

- Czas przymusu bezpośredniego

- Czas założonego wkłucia obwodowego przekraczający 72h(Funkcjonalność

dodatkowa – wg pozacenowego kryterium oceny ofert)

Strona 48 z 204

System nie posiada funkcji wyświetlania ostrzeżeń na liście pacjentów oddziału w

zakresie:

- Skala Norton, REAL, TORRANCE΄A.

- Ocena stanu odżywienia

- Liczba dni od założenia aktualnego cewnika

- Liczba dni cewnikowania

- Odleżyny

- Liczba dni od zakończenia poprzedniej hospitalizacji na oddziale

- Czas przymusu bezpośredniego

- Czas założonego wkłucia obwodowego przekraczający 72h

- 6

System musi zapewniać możliwość wyświetlania na liście pacjentów oddziału alertu o podejrzeniu zakażenia

szpitalnego wygenerowany po wpisaniu w dokumentację wartości przekraczające dopuszczalne normy (np.

temperatura powyżej 38°C)

- 7

System musi zapewniać możliwość wyszukiwania pacjenta do przyjęcia na oddział co najmniej według

poniższych kryteriów:

- Imię

- Nazwisko

- Pesel lub numer paszportu lub nadane ID pacjenta

- 8 System musi zapewniać możliwość przyjęcia na oddział pacjenta NN

- 9

System musi zapewniać możliwość przy przyjęciu pacjenta na oddział uzupełnienia danych przyjęciowych

co najmniej w zakresie:

- Wpis do kolejki

- Jednostka rozliczeniowa

- Tryb przyjęcia

Uprawnienia pacjenta

- Opiekun

- Karta DiLO

- Data przyjęcia

- Uzupełnienie skierowania

- Komentarz

- 10 System musi zapewniać możliwość nadania numeru księgi głównej i oddziałowej automatycznie lub ręcznie

- 11 System musi zapewniać możliwość automatycznego zawężania listy dokumentów do przypisanych do

konkretnego oddziału

- 12 System musi zapewniać możliwość wyświetlania listy dokumentów dodanych w ramach aktualnej

hospitalizacji z informacją o nazwie dokumentu, dacie dodania i osobie dodającej

- 13 System musi zapewniać możliwość podejrzenie historii zmian w dokumencie z wyszczególnieniem danych

dodanych, zmodyfikowanych oraz usuniętych

- 14 System musi zapewniać możliwość podejrzenia dokumentacji pacjenta w trakcie uzupełniania dokumentacji

bez wychodzenia z kontekstu dokumentu

- 15

System musi zapewniać możliwość przeglądania wystawionych zleceń pacjenta z oznaczeniem statusów co

najmniej w zakresie:

- Punkt pobrań

Strona 49 z 204

- Oczekuje

- Zrealizowane

- Anulowane

- 16

System musi zapewniać możliwość przeglądania najważniejszych informacji o pacjencie z ostatniego dyżuru

w jednym miejscu co najmniej w zakresie:

- Obserwacje lekarskie

- Obserwacje pielęgniarskie

- Parametry życiowe w formie wykresu z możliwością wyboru parametrów jakie na wykresie mają się

znaleźć

- Zlecenia leków (po nazwach międzynarodowych)

- Wyniki badań

- Doba pobytu

- 17

System musi zapewniać możliwość przeglądania wyników badań zleconych pacjentowi z możliwością

filtrowania co najmniej w zakresie:

- Rodzaj badania

- Zakres dat

- 18

System musi zapewniać możliwość przeglądania wyników badań laboratoryjnych w formie tabelarycznej z

oznaczeniem wartości odstających oraz w formie wykresu z możliwością wyboru parametrów znajdujących

się na wykresie.

- 19 System musi zapewniać możliwość zlecania leków.

- 20 System musi zapewniać możliwość wystawiania recept z możliwością kontynuacji leczenia na podstawie

recept wcześniej wystawionych.

- 21 System musi zapewniać możliwość wystawiania skierowań oraz e-skierowań.

- 22

System musi zapewniać możliwość przeglądania historii choroby pacjenta z możliwością sortowania co

najmniej w zakresie:

- Wyboru dokumentu

- Jednostki realizującej

- Wyboru świadczenia

- 23

System musi zapewniać możliwość uzupełnienia dokumentacji związanej z zakażeniami szpitalnymi, wraz z

automatycznym rozpoznaniem patogenu alertowego i wygenerowaniem wymaganych przepisami prawa

raportów, w tym sprawozdawczości w systemach NFZ.

- 24 System musi zapewniać możliwość wyświetlania listy braków w dokumentacji oraz wyświetlania

komunikatu w przypadku zatwierdzania dokumentu wypisu pacjenta

- 25

System musi zapewniać możliwość wystawiania zleceń co najmniej w zakresie:

- Laboratorium /analityka, patomorfologia/ mikrobiologia / toksykologia/

- Radiologia

- Rehabilitacja

- Zabieg operacyjny

- Konsultacja

- Procedura

- Pracownia

- Dializa

- 26 System musi zapewniać możliwość przypisania tożsamości do pobytu po zmianie danych w trakcie

hospitalizacji

Strona 50 z 204

- 27 System musi zapewniać możliwość kopiowania wpisanego rozpoznania do innych dokumentów

- 28 System musi zapewniać możliwość kopiowania wpisów z wcześniej dodanych tożsamych z wypełnianym

dokumentów

- 29 System musi zapewniać możliwość podzielenia oddziału na odcinki, stworzenie SOR oraz (osobno) izby

przyjęć

- 30 System musi zapewniać możliwość generowania wszystkich wymaganych prawnie raportów

- 31 System musi zapewniać możliwość ewidencji danych niezbędnych dla sporządzenia karty gorączkowej.

- 32 System musi zapewniać możliwość przeglądu karty gorączkowej, prezentacji interpretacji graficznej

wyników.

- 33 System z poziomu administracji musi posiadać możliwość definiowania własnych adnotacji do dokumentów,

które będą widoczne dla użytkowników w trakcie ich uzupełniania

- 34 System musi umożliwiać Elektroniczną Weryfikację Uprawnień Świadczeniobiorców.

- 35 System musi umożliwiać ewidencjonowanie i wydruk oświadczeń pacjenta/opiekuna prawnego

potwierdzających uprawnienie do świadczeń opieki zdrowotnej finansowanych ze środków publicznych

- 36

System musi umożliwiać wydruk opasek identyfikacyjnych zawierających dane dopuszczone prawem:

- dla pacjentów dorosłych w tym z izby przyjęć,

- dla dzieci.

- 37 System musi umożliwiać wydruk opasek identyfikatora ze zdjęciem dla dziecka, które nie ukończyło 6 r.ż. w

przypadku, gdy założenie opaski identyfikacyjnej dziecku jest niemożliwe.

- 38

Potwierdzenie przyjęcia na Oddział:

- nadanie numeru Księgi Oddziałowej – automatycznie z możliwością modyfikacji numeru,

- wprowadzenie daty i godziny przyjęcia

- wprowadzenie danych lekarza prowadzącego.

- przypisanie pacjentowi diety,

- przydzielenie pacjentowi łóżka,

- możliwość modyfikacji danych płatnika,

- wprowadzenie danych o rodzaju hospitalizacji dla celów statystycznych, np. hospitalizacja

całodobowa z zabiegiem operacyjnym, hospitalizacja dzienna bez zabiegów i badań laboratoryjnych

itp.

- 39 System musi umożliwiać rejestrację przyjęcia pacjenta na Oddział z określeniem trybu przyjęcia.

- 40 System musi umożliwiać przyjmowania pacjentów na turnusy.

- 41 System musi umożliwiać odmowę przyjęcia na oddział – zgłoszenie na Izbę Przyjęć żądania anulowania

przyjęcia.

- 42 System musi umożliwiać przegląd i aktualizację danych personalnych.

- 43 System musi umożliwiać monitorowanie stanu obłożenia Oddziału (moduł musi dopuszczać przyjęcie

pacjenta nawet, gdy nie ma wolnych łóżek na Oddziale z zaznaczeniem tego faktu np. poprzez adnotację).

- 44 System musi umożliwiać wprowadzenie rozpoznań: wstępnych, końcowych, przyczyny zgonu.

Strona 51 z 204

- 45 System musi umożliwiać pobranie rozpoznania z listy wcześniejszych pobytów na oddziale danego pacjenta.

- 46 System musi umożliwiać zablokowanie zamknięcia hospitalizacji w przypadku braku karty zgłoszenia

choroby nowotworowej/zakaźnej, jeśli pacjent ma rozpoznanie nowotworowe/zakaźne.

- 47 System musi umożliwiać definiowanie przez administratora minimalnego zbioru danych, który musi być

uzupełniony przed zamknięciem hospitalizacji pacjenta.

- 48 System musi umożliwiać przekazanie do wykonania procedur zabiegowych w gabinetach zabiegowych

oddziału.

- 49 System musi umożliwiać wpisanie pacjenta do księgi oczekujących na dalsze świadczenia.

- 50 System musi umożliwiać planowanie kolejnych wizyt w ramach kontynuacji leczenia lub wizyt

poszpitalnych.

- 51 System musi umożliwiać obsługę kart diagnostyki i leczenia onkologicznego (DiLO).

- 52 System musi umożliwiać przyjęcie pacjenta na podstawie karty DiLO.

- 53 System musi umożliwiać weryfikację zgodności danych oraz kompletu danych niezbędnych do przyjęcia

pacjenta na podstawie karty DiLO, w tym tryb przyjęcia, numer karty, etap realizacji karty.

- 54 System musi umożliwiać założenie karty DiLO w trakcie trwania świadczenia.

- 55 System musi umożliwiać założenia kolejnej karty DiLO pacjenta dla drugiej grupy rozpoznań bez

konieczności zamykania aktywnej karty.

- 56 System musi umożliwiać zablokowanie zakładania kilku aktywnych kart DiLO dla pacjenta.

- 57 System musi umożliwiać wydruk karty DiLO w wybranym trybie: tylko strony dot. obsługiwanego etapu

karty, wszystkie strony, objaśnienia.

- 58 System musi umożliwiać realizację kilku etapów karty DiLO podczas jednego świadczenia.

- 59 System musi umożliwiać zamknięcie karty DiLO podczas realizacji świadczenia.

- 60 System musi umożliwiać anulowanie wprowadzonej karty DiLO.

- 61 System musi umożliwiać usunięcia informacji o realizacji etapu karty DiLO w ramach świadczenia bez

konieczności usuwania całej karty.

- 62 System musi umożliwiać podgląd listy świadczeń, w ramach których następuje realizacja kolejnych etapów

obsługi karty DiLO.

- 63

System musi umożliwiać wypełnianie i wydruk standardowych druków zewnętrznych:

- Karta Statystyczna,

- Karta Leczenia Żywieniowego,

- Karta Zgłoszenia Choroby Zakaźnej,

- Karta Zgłoszenia Choroby Nowotworowej,

- Karta Zgonu,

- Karta Informacyjna z leczenia szpitalnego,

- Odstąpienie od sekcji zwłok z możliwością złożenia elektronicznego podpisu przez członka rodziny

upoważnionego wcześniej bądź przedstawiciela ustawowego.

Strona 52 z 204

- 64 System musi umożliwiać obsługę dyżurów lekarskich.

- 65 System musi umożliwiać blokowanie wypisu przy braku potwierdzenia kompletności dokumentacji

medycznej pacjenta.

- 66 System musi posiadać mechanizmy weryfikujące daty procedur medycznych oraz rozliczeniowych z datami

pobytu pacjenta.

- 67 System musi umożliwiać poinformowanie lekarza prowadzącego za pomocą komunikatu o uzupełnieniu

informacji o planowanej dacie wypisu pacjenta z oddziału.

- 68 System musi umożliwiać ewidencję danych do rozliczenia kontraktowanych produktów z płatnikiem, w tym

rozliczanie kart TISS28.

- 69 System musi umożliwiać parametryzację kart informacyjnych leczenia szpitalnego – dla każdego oddziału

osobno.

- 70 System musi umożliwiać ewidencję wystawionych recept zgodnie z obowiązującymi przepisami.

- 71

System musi umożliwiać tworzenie, obsługę i monitowanie różnych ścieżek postępowania z pacjentem

obejmujących zdarzenia medyczne realizowane poprzez usługi ambulatoryjne, hospitalizacyjne i

diagnostyczne.

- 72

System musi umożliwiać współpracę z czytnikami kodów kreskowych w zakresie co najmniej identyfikacji

pacjenta po kodzie zamieszczonym na dokumentacji medycznej oraz pracownika po identyfikatorze

osobowym.

- 73 System musi umożliwiać współpracę z czytnikami dowodów osobistych w zakresie co najmniej

odczytywania danych pacjenta: nazwisko, imię, PESEL, nr dowodu osobistego.

- 74 System musi umożliwiać limitowanie dostępu do danych wyłącznie osobom uprawnionym, poprzez

konfigurowanie schematów uprawnień.

- 75

System musi umożliwiać generowanie raportów (zakres minimalny):

- obłożenie łóżek Oddziału na określony dzień,

- zestawienie nowoprzyjętych/wypisanych pacjentów do Oddziału dzień/godzina),

- zestawienie pacjentów oczekujących na przyjęcie na Oddział,

- zestawienie pacjentów hospitalizowanych wg czasu pobytu (powyżej X dni),

- zestawienie pacjentów wg jednostki chorobowej (rozpoznanie zasadnicze),

- średni czas pobytu (szpital/Oddział),

- średni czas pobytu wg jednostki chorobowej (rozpoznania zasadniczego),

- miesięczne zestawienie ilości przyczyn zgonów,

- zestawienie przyjęć wg województwa, ubezpieczyciela,

- zestawienie przyjęć do szpitala wg lekarza kierującego i przyjmującego.

- 76 System musi umożliwiać wgląd w dane matki z poziomu danych medycznych noworodka bez konieczności

osobnego wyszukiwania matki jako innego pacjenta.

- 77

System musi umożliwiać ewidencję danych porodu, co najmniej w zakresie:

- wywiadu przedporodowego (badania położniczego),

- wpisu do Księgi Porodów,

- odnotowania danych noworodka (medyczne, skala Apgar),

- odnotowania badania przedmiotowego noworodka,

- odnotowania informacji o zabiegach i powikłaniach.

Strona 53 z 204

- 78 System musi umożliwiać prowadzenie książki transfuzyjnej zgodnie z rozporządzeniem o leczeniu krwią).

- 79 Możliwość zamawiania składników krwi (zgodnie z rozporządzeniem o leczeniu krwią).

- 80 System musi umożliwiać obsługę zgłaszania zdarzeń niepożądanych (zgodnie z rozporządzeniem o leczeniu

krwią) z poziomu modułu zdarzeń niepożądanych.

- 81

System musi umożliwiać automatyczne rozpoznawanie konieczności podpowiadania zakresu umowy

dotyczących świadczeń, które nie są wykonywane na podstawie karty DiLO, a dotyczą rozpoznań

onkologicznych.

7.1.1.10 Panel lekarski

Lp. Opis wymagania / punktacja

1. System musi umożliwiać wybór graficznej lub tabelarycznej prezentacji wyników badań laboratoryjnych.

2. System musi umożliwiać prezentację przekroczeń norm w graficznej i tabelarycznej formie wyników badań

laboratoryjnych.

3. System musi umożliwiać definiowanie (przypinania do panelu) w panelu aktywnej listy formularzy oraz

raportów, a z których użytkownicy najczęściej korzystają.

4. System musi umożliwiać stosowanie filtrów listy pacjentów obejmujące:

- pacjentów tylko lekarza prowadzącego,

- pacjentów lekarza prowadzącego oraz innych prowadzących,

- pacjentów tylko z aktualnej jednostki organizacyjnej szpitala,

- pacjentów z wszystkich jednostek organizacyjnych szpitala,

- aktualnych pacjentów,

- wypisanych pacjentów,

- pacjentów z zadaniami do wykonania,

- pacjentów z innych oddziałów z leczeniem skojarzonym,

- pacjentów z innych oddziałów oczekujących na konsultacje.

5. System musi umożliwiać sortowanie pacjentów według:

- daty przyjęcia,

- nazwiska i imienia,

- sali i łóżka.

6. System musi umożliwiać tekstowe wyszukiwanie pacjentów z listy pacjentów.

7. System musi umożliwiać tekstowe wyszukiwania elementów historii leczenia.

8. System musi umożliwiać ograniczanie wyświetlanych w panelu danych dotyczących danego pacjenta z okresu:

- ostatnie 24h,

- ostatnie 72h,

- wybrany dzień,

- zakres dat od do.

9. System musi umożliwiać konfigurowanie wyświetlanych danych w obszarze dotyczącym danego pacjenta w

zakresie min.:

- imię,

Strona 54 z 204

- nazwisko,

- płeć,

- data urodzenia,

- PESEL,

- nr w Książce Oddziałowej,

- nr w Księdze Głównej,

- sala/łóżko,

- rodzaj diety,

- lekarz prowadzący.

10. System musi umożliwiać rejestrację danych o:

- krwi (grupa, Rh, fenotyp, przeciwciała, VDRL, HBS, HCV, HIV) i wszystkich zmian dotyczących grupy

krwi pacjenta,

- ewidencja informacji o źródle danych dotyczących grupy krwi,

- możliwość wymuszenia dodatkowego podania hasła przed modyfikacją danych dotyczących grupy krwi,

- podstawowych badaniach,

- informacjach ginekologicznych.

11. System musi umożliwiać redefiniowanie znaczenia pól opisowych wywiadu w zależności od wymagań

poszczególnych oddziałów/poradni.

12. System musi umożliwiać definiowanie przez użytkownika szablonów dla wywiadu, osobno dla każdego z pól

opisowych, z możliwością przypisania szablonu dla jednostki organizacyjnej bądź wszystkich jednostek

organizacyjnych.

13. System musi umożliwiać kopiowanie danych z poprzedniego wywiadu.

14. System musi umożliwiać kopiowanie do wywiadu dowolnej informacji dostępnej w systemie

15. System musi umożliwiać rejestrację danych o stosowanych lekach i alergiach. System musi posiadać

predefiniowane katalogi międzynarodowych nazw, substancji oraz produktów.

16. System musi umożliwiać rejestrację danych o badaniach przedmiotowych z opcją definiowania szablonów dla

poszczególnych oddziałów osobno. Możliwość podziału badań przedmiotowych na klasy i ich oddzielna obsługa.

17. System musi umożliwiać skopiowanie poprzedniego wyniku badania do bieżącego z możliwością jego edycji po

skopiowaniu.

18. System musi umożliwiać ustawienie dla każdego badania wartości domyślnej, wstawianej po wczytaniu szablonu,

bądź danego badania.

19. System musi umożliwiać ustawianie wartości domyślnej dla wybranych pól.

20. System musi umożliwiać domyślne wczytanie poprzedniej wartości badania.

21. System musi umożliwiać ewidencjonowanie badań przedmiotowych w strukturze hierarchicznej i ich prezentację

za pomocą tzw. „drzewa”.

22. System musi umożliwiać wprowadzenie rozpoznań: wstępnych (z Izby Przyjęć lub SOR), zasadniczych,

współistniejących.

23. System musi umożliwiać wprowadzenie dodatkowych informacji o chorobach: przebytych chorobach, chorobach

w rodzinie.

24. System musi umożliwiać wprowadzenie informacji dotyczących planu opieki, o obserwacjach lekarskich.

Strona 55 z 204

25. System musi umożliwiać definiowanie klasyfikacji i szablonów dla planu opieki i obserwacji lekarskich.

26. System musi umożliwiać definiowanie dowolnych kategorii obserwacji (innych niż lekarskie) i ich osobna

obsługa.

27. System musi umożliwiać generowanie obserwacji lekarskich na podstawie udzielonych konsultacji.

28. System musi umożliwiać automatyczne dodawania procedury medycznej na podstawie zrealizowanej konsultacji

29. System musi umożliwiać pobieranie wyników diagnostycznych oraz laboratoryjnych z danego dnia do obserwacji

lekarskich.

30. System musi umożliwiać ewidencjonowanie obserwacji lekarskich wszystkich pacjentów oddziału na jednym

ekranie.

31. System musi umożliwiać wypełnienie automatycznie karty informacyjnej w oparciu o zgromadzone dane o

leczeniu (wyniki laboratoryjne, diagnostyczne, rozpoznania, procedury).), z. Z możliwością ustawienia sposobu

ich wyświetlania (sortowanie).

32. System musi umożliwiać zdefiniowanie sposobu wyświetlania/sortowania wyników laboratoryjnych,

diagnostycznych, rozpoznań, procedur medycznych na karcie informacyjnej.

33. System musi umożliwiać definiowanie przez użytkownika szablonów dla poszczególnych pozycji zawartych w

karcie informacyjnej.

34. System musi umożliwiać przeglądanie epikryz z poszczególnych pobytów danego pacjenta.

35. System musi umożliwiać kopiowanie informacji z dowolnej poprzedniej epikryzy do bieżącej, z możliwością jej

edycji po skopiowaniu.

36. System musi umożliwiać definiowanie przez użytkownika szablonów dla epikryz.

37. System musi umożliwiać przeglądanie wywiadów z poszczególnych pobytów.

38. System musi umożliwiać przypominanie o wypełnieniu dokumentu związanego ze stanem odżywienia,

monitorowaniem bólu, zakażeniami, oceną geriatryczną, oceną zagrożenia wystąpienia odleżyn, oceną kategorii

pacjenta (wywiad epidemiologiczny).

39. System musi umożliwiać wprowadzanie informacji związanych z podjętymi resuscytacjami, ich przyczynami,

skutecznością – dokonywanie analiz, generowanie raportów.

40. System musi umożliwiać generowanie informacji o zaistniałych zgonach pacjentów, w tym zgonach

okołooperacyjnych, w wypadku gdy zgon zakwalifikowany zostanie jako zdarzenie niepożądane – zdarzenie

musi zostać zarejestrowane w module zdarzeń niepożądanych.

41. System musi umożliwiać wprowadzanie danych i analiz związanych z podjętymi działaniami resuscytacyjnymi

prowadzonymi w oddziałach.

42. System musi umożliwiać rejestrację zdarzeń niepożądanych związanych z udzielaniem świadczeń w oddziałach.

43. System musi umożliwiać zlecanie pacjentowi konsultacji lekarskich.

44. System musi umożliwiać przegląd wyników konsultacji lekarskich.

45. System musi umożliwiać wystawianie różnego rodzaju zaświadczeń np. potwierdzenia przyjęcia do szpitala /

Strona 56 z 204

pobytu w szpital, ZUS ZLA. Wymagana możliwość korzystania z gotowych szablonów zaświadczeń

46. System musi umożliwiać tworzenie przez administratora własnych szablonów zaświadczeń z możliwością

pobierania do nich informacji z systemu za pomocą zdefiniowanych w systemie zmiennych, możliwość

samodzielnego definiowania takich zmiennych.

47. System musi umożliwiać wypisywanie recept z wykorzystaniem aktualnej listy leków refundowanych

(informacja o poziomach odpłatności wraz z zakresem wskazań refundacyjnych).

48. System musi umożliwiać administratorowi lub wyznaczonej osobie bezpośrednie zaczytywanie listy leków

refundowanych na podstawie pliku .xls publikowanego przez Ministerstwo Zdrowia.

49. System musi automatycznie nadawać numery recept z puli zaczytanej do systemu dla danego lekarza.

50. System musi umożliwiać konfigurację informacji wyświetlanej dla lekarza ostrzegającej o przekroczeniu

51. minimalnej liczby dostępnych numerów recept.

52. System musi umożliwiać kopiowanie zestawu zapisanych leków z recept wystawionych w przeszłości.

53. System musi umożliwiać wystawienie recepty dla seniora 75+ dla jednostek POZ.

54. System musi umożliwiać wystawienie recepty typ: Rp, Rpw, Rpz, recepturowej, transgranicznej

55. System musi umożliwiać definiowanie przez lekarza szablonów zestawów leków do zapisania na recepcie

56. System musi umożliwiać generowanie następujących wydruków:

- wywiadu,

- badań przedmiotowych,

- planu opieki

- obserwacji lekarskich,

- epikryz,

- kart informacyjnych,

- skierowań na konsultacje,

- zaświadczeń,

- recept oraz informacji o wystawionej recepcie elektronicznej

- skierowań do jednostek zewnętrznych (poradnia specjalistyczna, szpital, pracownia, szpital

psychiatryczny, zabiegi fizjoterapeutyczne),

- historii choroby pacjenta leczonego operacyjnie w trybie jednodniowy,

- karty kwalifikacyjnej do zabiegu operacyjnego w trybie jednodniowym,

- zgody pacjenta na operację w trybie jednodniowym,

- karty żywienia pozajelitowego,

- kart monitorowania i leczenia bólu

- karty oceny geriatrycznej pacjenta

- karty zastosowania przymusu bezpośredniego

- oceny ryzyka związanego ze stanem odżywienia (nutritionalriskscore - NRS),

- subiektywnej globalnej oceny stanu odżywienia, (SGA)

- zlecenia zapotrzebowania na sprzęt ortopedyczny,

- zlecenia zapotrzebowania na sprzęt ortopedyczny comiesięczny,

- skierowania na leczenie uzdrowiskowe,

- wniosku o refundację sprowadzanego z zagranicy środka spożywczego specjalnego przeznaczenia

Strona 57 z 204

żywieniowego niezbędnego dla ratowania życia lub zdrowia,

- zapotrzebowania na sprowadzany z zagranicy produkt leczniczy niezbędny dla ratowania życia lub

zdrowia,

- zapotrzebowania na sprowadzany z zagranicy środek spożywczy specjalnego przeznaczenia

żywieniowego, niezbędny dla ratowania życia lub zdrowia.

57. System musi umożliwiać współpracę z czytnikami kodów kreskowych w zakresie identyfikacji pacjenta,

pracownika oraz leków.

58. System musi umożliwiać rejestrację głosu z wykorzystaniem dyktafonów.

59. System musi umożliwiać dodawanie dowolnych plików powiązanych z danym pacjentem oraz wizytą lub

hospitalizacją.

60. System musi umożliwiać dołączanie do EDM i archiwizowanie zeskanowanych dokumentów z formy

papierowej.

61. System musi posiadać mechanizm konfiguratora formularzy, umożliwiający administratorowi tworzenie

formularzy z możliwością zdefiniowania w nich minimum:

- pól opisowych,

- pól opisowych z konfigurowalną przez użytkownika listą podpowiedzi,

- pól wyboru (checkbox),

- pól radiowych,

- pól pobierających dane z systemu,

- przycisków,

62. System musi umożliwiać skonfigurowanie standardowego wydruku dla konfigurowalnego formularza z opcją

drukowania całego formularza lub tylko wypełnionych/zaznaczonych wartości.

63. System musi posiadać mechanizm blokowania ewidencji danych w historii choroby pacjenta po określonym

czasie.

64. System musi posiadać mechanizm blokujący możliwość edycji lub usunięcia wpisu dla osoby nie będącej jej

autorem, ustawiany indywidualnie dla formularza.

65. System musi umożliwiać wygenerowanie raportu z liczbą dni od zakończenia poprzedniej hospitalizacji na

oddziale z możliwością monitorowania readmisji

66. System musi umożliwiać wyświetlania alertów na liście pacjentów co najmniej w zakresie:

- czasu przymusu bezpośredniego – z możliwością generowania z systemu formularzy do zgłaszania

przymusu, przedłużenia stosowania przymusu bezpośredniego oraz jego monitorowania

- podejrzenia zakażenia szpitalnego – alert wygenerowany po wpisaniu w dokumentację wartości

przekraczające dopuszczalne normy (np. temperatura powyżej ustalonej, biochemiczne wykładniki stanu

zapalnego lub inne zdefiniowane przez użytkownika) z jednoczesnym wpisem w module zakażeń

szpitalnych i – jeśli wymagane – następowym automatycznym raportowaniem w wymaganych

systemach sprawozdawczych (NFZ)

- pacjentów w oddziale powyżej 60 rż u których dokonano całościowej oceny geriatrycznej – wg

obowiązujących skal, które będą wymagane, z możliwością generowania raportów oraz automatycznym

przeniesieniem do modułu rozliczeniowego z NFZ

- konieczności zlecenia profilaktyki CHZZ

konieczność zlecenia profilaktyki okołooperacyjnej

Strona 58 z 204

67. System musi umożliwiać rejestrowanie zdarzeń niepożądanych – zgodnie z określonym katalogiem

68. System musi umożliwiać zlecanie czynności wykonywanych przez pielęgniarki, takich jak np:

- zmiana opatrunku

- usunięcie wkłucia centralnego

- profil glikemii z określeniem częstotliwości

- bilans płynów z określeniem częstotliwości (np. 24-, 12- , 6- godzinny lub godzinowy)

- monitorowanie ciśnienia, tętna, saturacji z określeniem częstotliwości (od 24-godzin do stałego)

69. System musi umożliwiać prowadzenie siatki centylowej

70. System musi posiadać formularze i raporty dla skal udarowych min. NIHSS

71. System musi posiadać formularze i raporty dla skal oceny ryzyka Żylnej Choroby Zakrzepowo Zatorowej

(ŻChZZ) min. Capriniego, Padewska.

72. System musi posiadać formularze i raporty dla skal pomocnych przy leczeniu zatruć min. PSS, CIWA-A, CIWA-

B, CIWA- AR

7.1.1.11 Ordynacja Lekarska

Lp. Opis wymagania / punktacja

1. System musi umożliwiać zlecenie leków pacjentowi z rozróżnieniem zlecenia określonego lokalnie i

zewnętrznego.

2. System musi umożliwiać filtrowanie zleceń wg daty wystawienia zlecenia, rodzaju zlecenia.

3. System musi umożliwiać sortowanie zleceń wg opisu zlecenia oraz daty planowanej realizacji.

4. System musi umożliwiać prezentację odpowiednich statusów realizacji zlecenia za pomocą różnych znaków

graficznych lub opisów tekstowych.

5. System musi umożliwiać wybór leków z receptariusza oddziałowego poprzez podanie nazwy międzynarodowej

lub handlowej.

6. System musi umożliwiać zlecanie leków recepturowych zdefiniowanych w module Apteka.

7. System musi umożliwiać zlecanie leków spoza receptariusza.

8. System musi umożliwiać zlecanie leków poprzez podanie nazwy międzynarodowej (po stronie ordynacji leków).

9. System musi umożliwiać uszczegółowienie zlecenia na konkretne podanie leku o nazwę handlową. Opcja

włączana i wyłączana przez administratora systemu.

10. System musi umożliwiać zlecanie w trybie zwykłym, doraźnym oraz do decyzji lekarza dyżurnego.

11. System musi umożliwiać określenie godziny i czasu realizacji zlecenia.

12. System musi umożliwiać lekarzowi podgląd wykazu alergenów, na które uczulony jest pacjent.

13. System musi umożliwiać ewidencjonowanie dodatkowych środków i rozpuszczalników w ramach jednego

zlecenia lekowego.

Strona 59 z 204

14. System musi umożliwiać lekarzowi podgląd szczegółów dotyczących realizacji zlecenia.

15. System musi umożliwiać konfigurację przedziału czasu, na jaki można ewidencjonować zlecenia.

16. System musi umożliwiać szybkie zaewidencjonowanie odstawienia leku.

17. System musi umożliwiać zbiorcze przyjmowanie zleceń przez pielęgniarkę.

18. System musi umożliwiać pielęgniarkom wyświetlenie zleceń lekowych z określonego zakresu czasu (dyżuru),

dla konkretnego pacjenta i dla konkretnej sali, na której leżą pacjenci.

19. System musi umożliwiać sortowanie zleceń o określonym statusie realizacji.

20. System musi umożliwiać ewidencjonowanie uwag dotyczących realizacji zlecenia.

21. System musi umożliwiać zamknięcie zlecenia lekowego bez jego realizacji. W tej sytuacji powód niemożliwości

realizacji zlecenia musi być bezwzględnie określony.

22. System musi umożliwiać automatyczne przyjmowanie, rozpisanie i realizację leków na podstawie aktualnego

stanu magazynowego apteczki oddziałowej.

23. System musi umożliwiać wydruk zleceń na środki farmaceutyczne zarówno wg pacjentów, jak i wg zleconych

leków.

24. System musi umożliwiać rozdział zleceń dla pielęgniarki lekowej (tabletki, kapsułki, etc.) i zabiegowej

(iniekcje).

25. System musi realizować proces rejestracji podania leków ‘przy łóżku pacjenta’, wraz z rejestracją ew. przebiegu

podania (nie przyjęcia).

26. System musi umożliwiać współpracę z czytnikami kodów kreskowych i kolektorami danych przy ewidencji

podania leków pacjentowi.

27. System musi umożliwiać prowadzenie księgi realizacji zleceń lekarskich.

28. System musi umożliwiać synchronizację pomiędzy kartą zleceń lekarskich, a księgą zabiegów pielęgniarskich.

29. System musi posiadać mechanizm definiowania dodatkowych filtrów ograniczających listę zleceń. Użytkownik

może zaznaczyć więcej niż jeden filtr w danym momencie.

7.1.1.12 Opieka pielęgniarska

Lp. Opis wymagania

1. System musi umożliwiać ewidencję diagnoz pielęgniarskich/problemów pielęgnacyjnych, co najmniej,

w zakresie:

- dokumentowania procesu pielęgnowania oraz procedur pielęgniarskich (Karta indywidualnej opieki

pielęgniarskiej) w oparciu o schematy definiowane dla danej jednostki za pomocą mechanizmu oznaczania

wykonania danej czynności przy pomocy checkboxa.

- wprowadzania diagnoz/problemów pielęgnacyjnych

- wprowadzania procedur wynikających z diagnozy//problemów pielęgnacyjnych

- ustalenia listy diagnoz//problemów pielęgnacyjnych preferowanych dla jednostki

- przegląd diagnoz//problemów pielęgnacyjnych z poprzednich pobytów pacjenta

- realizacji procedur wynikających z diagnoz/problemów pielęgnacyjnych

Strona 60 z 204

- dodania lub usuwania wielu procedur jednocześnie

- odnotowania realizacji wielu procedur jednocześnie

- edycji opisu wykonanej procedury

- wydruku indywidualnej karty procesu pielęgnacji

- zbiorczej realizacji procedur wynikających z jednej lub wielu diagnoz//problemów pielęgnacyjnych

2. System musi umożliwiać powielenie obserwacji

3. System musi umożliwiać odnotowanie realizacji wielu zleceń pielęgniarskich jednocześnie.

4. System musi umożliwiać wycofanie operacji realizacji lub odrzucenia zlecenia pielęgniarskiego.

5. System musi umożliwiać rejestrację informacji o stanie zdrowia pacjenta

6. System musi umożliwiać wprowadzanie obserwacji pielęgniarskich (karty realizacji opieki) z możliwością

pobierania szablonów z katalogu oraz możliwością samodzielnego definiowania szablonów przez użytkownika.

7. System musi umożliwiać dokumentowanie procesu pielęgnowania w oparciu o Diagnozę/Problem pielęgniarski,

Plan realizacji opieki/Realizację opieki, Ocenę realizacji opieki z możliwością definiowania własnych szablonów

diagnoz, z dedykowanymi dla nich czynnościami oraz ocenami wybieranymi z list wielowartościowych.

8. System musi umożliwiać ewidencjonowanie informacji o odleżynach oraz podjętych czynnościach pielęgnacyjnych

dotyczących odleżyn. Definiowanie szablonów przez użytkownika.

9. System musi umożliwiać prowadzenia bilansu płynów ze zgromadzonych informacji o płynach podanych i płynach

wydalonych.

10. System musi umożliwiać automatyczne obliczanie bilansu płynów zmianowego i dobowego na podstawie

wprowadzonych wartości liczbowych.

11. System musi umożliwiać definiowanie przez administratora w formularzu bilansu płynów dowolnych dodatkowych

źródeł płynów wydalonych, z możliwością ewidencji dla nich wartości w ml, które są uwzględniane w bilansie

zmianowym i dobowym.

12. System musi umożliwiać wprowadzanie zaleceń pielęgniarskich w rozbiciu na 3 pola z możliwością zdefiniowania

ich nagłówków przez administratora.

13. System musi umożliwiać definiowanie szablonów zaleceń dla wszystkich pól jednocześnie lub indywidualnie dla

każdego pola.

14. System musi umożliwiać pobrania zatwierdzonych zaleceń do karty informacyjnej.

15. Ewidencja opieki nad pacjentem w skali TISS:

- wykaz procedur z dnia wraz z punktacją,

- automatyczne sumowanie procedur,

- określenie pracownika wykonującego.

16. System musi umożliwiać kopiowanie wykonanych procedur w ramach opieki w skali TISS w ramach

poszczególnych dni pobytu.

17. System musi umożliwiać automatyczne generowanie produktów zgodnie z NFZ na podstawie wprowadzonych

danych z zakresu TISS.

18. System musi umożliwiać generowanie następujących wydruków:

- opieka nad pacjentem w skali TISS – na dany dzień,

- zestawienie zbiorcze ilości punktów w ramach pobytu.

Strona 61 z 204

- Implementacja kalkulatora przeliczającego na podstawie masy, wzrostu, wyników

- laboratoryjnych - parametry pacjenta:

- powierzchnia,

- BMR (kcal, kJ), BMI,

- Osmol. Surowicy,

- BUN i UUN.

19. System musi umożliwiać ewidencjonowanie i wydruk karty obserwacji wkłuć: obwodowych, centralnych

dializacyjnych, dotętniczych.

20. System musi umożliwiać ewidencjonowanie w karcie wkłuć minimum danych:

- daty i godziny założenia wkłucia,

- osoby zakładającej,

- rodzaju zestawu,

- miejsca wkłucia,

- obserwacji wkłucia na podstawie 6 stopniowej skali z datą godziną i osobą wykonującą obserwację,

- usunięcia wkłucia,

- uwag.

21. System musi umożliwiać oznaczanie kolorem wkłuć w zależności od czasu, który upłynął od momentu jego

założenia np. czerwonym wkłucie obwodowe powyżej 72h od założenia

22. System musi umożliwiać dodawanie dowolnych plików powiązanych z danym pacjentem oraz pobytem/wizytą.

23. System musi umożliwiać dołączanie zeskanowanych dokumentów z formy papierowej.

24. System musi umożliwiać uzupełnienie wywiadu pielęgniarskiego o ocenę: sprawności pacjenta, stanu

emocjonalnego pacjenta, stanu psychicznego pacjenta.

25. System musi umożliwiać wydruk karty gorączkowej.

26. System musi umożliwiać ewidencję pomiarów dokonywanych pacjentowi wg ustalonej przez użytkownika

kolejności.

27. System musi umożliwiać definiowanie słowników wartości mierzonych i korzystanie ze słownika podczas

odnotowywania pomiaru.

28. System musi umożliwiać wydruk siatek centylowych dla pomiaru wzrostu, wagi, obwodu głowy i BMI dla

pacjentów w różnych grupach wiekowych.

29. System musi umożliwiać wprowadzanie opisów czynności pielęgnacyjnych/ zaleceń pielęgniarskich.

30. System musi umożliwiać wprowadzanie opisów wywiadu pielęgniarskiego.

31. System musi umożliwiać wprowadzanie opisów historii pielęgnowania.

32. System musi umożliwiać podgląd opisów zleceń i wywiadów pielęgniarskich dla całej hospitalizacji pacjenta, a nie

tylko dla bieżącego pobytu.

33. System musi umożliwiać określanie kategorii opieki pielęgniarskiej dla pacjenta.

34. System musi umożliwiać automatyczne ustalanie kategorii opieki pielęgniarskiej dla pacjenta, na podstawie

kategorii określanych dla kryterium: aktywność fizyczna, odżywianie, wydalanie.

35. System musi umożliwiać przypisanie każdemu pacjentowi kategorii pielęgnacyjnej na dobę.

Strona 62 z 204

36. System musi posiadać mechanizm automatycznego kopiowania kategorii pielęgniarskiej z poprzedniej doby/zmiany

dla pacjenta z możliwością jej zmiany w dniu bieżącym.

37. System musi umożliwiać kategoryzację wszystkich pacjentów oddziału na jednym formularzu.

38. System musi umożliwiać kategoryzację pacjentów na podstawie wyboru z listy wartości w formularzach min. Karty

Indywidualnej Opieki, Zaleceń pielęgniarskich, Bilansu płynów, Karty realizacji opieki.

39. System musi umożliwiać wykorzystanie definiowanych formularzy do opisu przebiegu pielęgniarskiego

40. System musi umożliwiać tworzenie zapotrzebowania żywnościowego dla pacjentów oddziału z możliwością

przeliczenia ilości zamawianych posiłków wg przypisanych pacjentom diet

41. System musi umożliwiać uzupełnienie zapotrzebowania żywnościowego o zamówienia dodatkowych posiłków i

materiałów

42. System musi umożliwiać odnotowanie podania leku należącego do pacjenta

43. System musi umożliwiać tworzenie dokumentacji związanej z oceną stanu odżywiania pacjenta

44. Podczas tworzenia dokumentu oceny stanu odżywiania, system musi uzupełnić dokument danymi ostatnich

pomiarów

45. System musi umożliwiać podgląd karty bilansu płynów w ramach opieki pielęgniarskiej

46. System musi umożliwiać listy pacjentów na oddziale do pacjentów posiadających zlecenia z uwagami do podania

47. System musi umożliwiać podgląd aktualnych zleceń dla oddziału w jednym oknie z możliwością zawężenia listy

przynajmniej według statusu zadania, sali, wybranego pacjenta, oraz drogi podania.

48. System musi umożliwiać oznaczanie na w oknie realizacji kolorami statusu dawki leku co najmniej potwierdzone,

zrealizowane, wstrzymane z podaniem przyczyny oraz zaplanowane - do potwierdzenia.

49. System musi umożliwiać oznaczanie w oknie realizacji wykrzyknikiem leków zleconych w do podania w trybie

pilnym.

50. System musi umożliwiać zgłoszenie nierozliczonych podań leków.

51. System musi umożliwiać oznaczenie podania leku jako zrealizowane. System automatycznie podpowiada datę i

godzinę podania z możliwością jej zmiany. Użytkownik ma możliwość wpisania uwag do realizacji zlecenia z

możliwością tworzenia szablonów, odnotowania niepodania oraz ilości podanej i pobranej leku. System

automatycznie podpowiada jako zużytą partię, partię z najkrótszą datą ważności w Apteczce oddziałowejz

możliwością jej zmiany. Użytkownik ma możliwość wyboru zużytej partii łącznie z zamiennikami. Odnotowana

ilość leku pobranego automatycznie jest zdejmowana ze stanu Apteczki oddziałowej.

52. System musi umożliwiać wycofanie zużycia oraz wycofania realizacji zlecenia. Odnotowana a wycofana ilość leku

pobranego automatycznie jest przywracana na stan Apteczki oddziałowej.

53. System musi umożliwiać wydruk listy zaplanowanych leków do podania.

54. System musi umożliwiać podejrzenie historii zmian w dokumencie z wyszczególnieniem danych dodanych,

zmodyfikowanych oraz usuniętych.

55. System musi umożliwiać podejrzenie dokumentacji pacjenta w trakcie uzupełniania dokumentacji bez wychodzenia

z kontekstu dokumentu.

Strona 63 z 204

56. System musi umożliwiać przeglądanie najważniejszych informacji o pacjencie z ostatniego dyżuru w jednym

miejscu co najmniej w zakresie:

- Obserwacje lekarskie

- Obserwacje pielęgniarskie

- Parametry życiowe w formie wykresu z możliwością wyboru parametrów jakie na wykresie mają się

znaleźć

- Zlecenia leków (po nazwach międzynarodowych)

- Doba pobytu

57. System musi umożliwiać podejrzenie historii zmian w dokumencie z wyszczególnieniem danych dodanych,

zmodyfikowanych oraz usuniętych.

58. System musi umożliwiać podejrzenie dokumentacji pacjenta w trakcie uzupełniania dokumentacji bez wychodzenia

z kontekstu dokumentu.

59. System musi umożliwiać wpisanie do raportu danych dotyczących konkretnego pacjenta przebywającego na

oddziale w czasie za który sporządzany jest raport.

60. System musi umożliwiać wydrukowanie raportu pielęgniarskiego za daną zmianę pielęgniarską.

61. System musi umożliwiać ewidencję Karty Bilansu Płynów w ujęciu godzinowym.

62. System musi umożliwiać ewidencję Karty Wykonanych Czynności Pielęgniarskich w ujęciu godzinowym.

63. System musi umożliwiać prowadzenie kart obserwacji w oparciu o wykonaną procedurę np. Karta Obserwacji

Cewnika Moczowego.

64. System musi umożliwiać prowadzenie karty pomiarowej w ujęciu godzinowym.

65. System musi umożliwiać wprowadzenie do systemu kart obserwacji i monitorowania stanu pacjenta oraz

wykonanych czynności pielęgnacyjnych obowiązujących w Szpitalu, wymaganych przepisami prawa i standardami

akredytacyjnymi CMJ i generowania raportów.

7.1.1.13 Blok operacyjny

Lp. Opis wymagania

1 System musi umożliwiać przypisanie zespołów chirurgicznych i anestezjologicznych do wykonania danych

operacji z możliwością podglądu na oddziałach.

2 System musi umożliwiać zlecanie pacjentowi zabiegów operacyjnych na konkretny termin. Zlecenie przejmuje

elektronicznie moduł Blok Operacyjny.

3 System musi umożliwiać dodanie nowego podzabiegu (zabiegu wykonywanego jednocześnie z innym

zabiegiem).

4 System musi umożliwiać przeglądanie kolejki pacjentów oczekujących na operacje.

5 System musi umożliwiać planowanie zabiegów, w szczególności:

daty i godziny,

miejsca (sala operacyjna),

tytułu zabiegu,

planowanego zużycia materiałów wszczepialnych,

rodzaju znieczulenia,

Strona 64 z 204

inne uwagi.

6 System musi umożliwiać potwierdzanie przyjęcia pacjenta na wykonanie zabiegu.

7 System musi umożliwiać ewidencję danych dotyczących pacjenta:

rozpoznanie,

grupakrwi,

masaciała,

wzrost,

powierzchniaciała.

8 System musi umożliwiać uzupełnienie opisu przedoperacyjnego.

9 System musi umożliwiać podgląd wszystkich zabiegów chirurgicznych dla danego pacjenta.

10 System musi umożliwiać podgląd zrealizowanych procedur podczas poprzednich zabiegów.

11 System musi umożliwiać planowanie zabiegu do wykonania w późniejszym terminie.

12 System musi umożliwiać obsługę znaczników czasowych, w szczególności:

- wjazd na salę operacyjną,

rozpoczęcie znieczulenia,

rozpoczęcie operacji,

zakończenie operacji,

zakończenie znieczulenia / wybudzenie,

wyjazd z sali operacyjnej.

13 System musi umożliwiać prowadzenie ewidencji m.in.:

Księgi Bloku Operacyjnego,

Księgi Znieczuleń,

wykonanych procedur medycznych,

dokumentacji operacyjnej, w tym karty zabiegowej pacjenta (podać przykład),

protokołów pielęgniarskich

zużytych leków i materiałów wraz z kosztami.

14 System musi umożliwiać generowanie raportów zdefiniowanych przez użytkownika, takich jak m.in.:

koszt zabiegu na pacjenta

wykorzystanie sal (czas),

statystyka pracownika,

czas trwania zabiegu operacyjnego

czas trwania znieczulenia

wszystkie przekrojowe analizy na podstawie wprowadzonych danych.

automatyczne przenoszenie danych dotyczących kosztu zabiegu na pacjenta do modułu KKL oraz

automatyczne przenoszenie statystyk (w ujęciu miesięcznym ) wszystkich procedur do modułu

koszty w celu wyliczenia kluczy podziałowych

15 System musi umożliwiać obsługę elektronicznych zleceń:

wysłanie zlecenia wykonania elementu leczenia (badania) do jednostki realizującej (np. pracownia

diagnostyczna, zakład patomorfologii),

możliwość śledzenia stanu wykonania zlecenia,

Strona 65 z 204

zwrotne otrzymanie wyniku realizacji zlecenia (np. wyniku badania).

16 System musi umożliwiać wprowadzanie danych związanych z podaniem profilaktyki okołooperacyjnej min. lek,

dawka, data, godzina z minutami.

17 System musi umożliwiać generowanie raportów z zastosowanej profilaktyki okołooperacyjnej – min. lek, dawka,

rodzaj zabiegu, data i godzina z minutami podania, lekarz zlecający, pielęgniarka realizująca zlecenie.

18 System musi umożliwiać zdefiniowanie listy typowych opisów przedoperacyjnych powiązanych z planowaną

główną procedurą.

19 System musi umożliwiać planowane zabiegów bez powiązania z pobytem pacjenta na oddziale lub w izbie

przyjęć.

20 System musi umożliwiać podanie planowanej jednostki realizującej leczenie (oddziału, na który zostanie przyjęty

pacjent).

21 System musi umożliwiać wprowadzenie personelu biorącego udział w operacji z podziałem na funkcje:

anestezjolog,

instrumentariusz,

lekarz operujący,

lekarze asystujący,

pielęgniarka anestezjologiczna,

pielęgniarka instrumentacyjna,

obserwatorzy i goście,

inne funkcje (konfigurowalne).

22 System musi umożliwiać niezależną ewidencji zespołu planowanego i realizującego (domyślnie zespół

planowanystajesięrealizującymwmomencieprzyjęciazabiegunablok,zmożliwościąpóźniejszej zmiany).

23 System musi umożliwiać zdefiniowanie i wykorzystanie podczas planowania domyślnych zespołów

operacyjnych (globalnie lub dla każdej Sali operacyjnej).

24 System musi umożliwiać skonfigurowanie, czy podanie operatora na etapie planowania zabiegu jest

obowiązkowe.

25 System musi umożliwiać wprowadzanie danych o zabiegu operacyjnym z uwzględnieniem ich minimalnego

zestawu:

Rozpoznanieprzedoperacyjne,

Rodzajzabiegu,

zgoda pacjenta nazabieg,

godzina przybycia, rozpoczęcia zabiegu, zakończenia zabiegu (z rozróżnieniemczasu zabiegu wg

chirurga i bloku operacyjnego).

podgląd bezpośrednio w formularzu informacji o grupie krwi, masie i wzrościepacjenta

wprowadzonych do historii choroby.

26 Wprowadzanie danych dotyczących chorób zakaźnych:

HIV,

HBS,

Gruźlica,

Inne.

27 System musi umożliwiać wprowadzanie opisowych danych o przebiegu operacji.

Strona 66 z 204

28 System musi umożliwiać wprowadzenie danych o znieczuleniach wykonanych podczas zabiegu:

ryzyko,

anestezjolog,

podaneleki.

29 System musi umożliwiać ewidencjonowanie wielu znieczuleń podczas zabiegu, każde z poniższym zestawem

danych:

godzina rozpoczęcia izakończenia,

rodzajznieczulenia,

uwagi (opisznieczulenia).

30 System musi umożliwiać zdefiniowanie typowych opisów dla poszczególnych rodzajów znieczuleń.

31 System musi umożliwiać wprowadzenie danych o materiałach medycznych i narzędziach zastosowanych podczas

zabiegu.

32 System musi umożliwiać prowadzenie analizy znieczuleń i zdarzeń niepożądanych ze znieczuleniem wg

ustalonego katalogu z jednoczesną rejestracją zdarzeń niepożądanych w module zdarzeń niepożądanych

33 System musi umożliwiać bieżącą i automatyczną aktualizację stanów magazynowych apteczek bloku

operacyjnego, sterylizatorni i apteczek anestezjologicznych na podstawie, np. zewidencjonowanego zużycia, a

także zużycia sprzętu wszczepialnego będącego na stanie apteki, sterylizacji lub w komisie po wprowadzeniu

zmian przez operatora.

34 System musi umożliwiać odnotowywanie zużycia sprzętu jednorazowego oraz narzędzi.

35 System musi umożliwiać obsługę bloku operacyjnego szpitala oraz wszelkich innych sal i gabinetów

zabiegowych lecznictwa zamkniętego i otwartego Szpitala.

36 System musi umożliwiać prowadzenie Księgi Zabiegów obejmującej także wszelkie procedury zabiegowe w

trybie ambulatoryjnym.

37 System musi umożliwiać generowanie formularza zgody pacjenta na zabieg.

38 Księga Bloku Operacyjnego musi umożliwiać generowanie schematów opisów zabiegu do wyboru.

39 System musi umożliwiać podział kosztów Bloku na poszczególne Oddziały zlecające, w szczególności koszty

materiałów medycznych i leków, które zamawia Blok Operacyjny muszą obciążać Oddziały macierzyste

pacjenta, który trafia na operację.

40 System musi umożliwiać obsługę pracowni wszystkich specjalności realizowanych przez Zamawiającego.

41 System musi umożliwiać ewidencję i wydruk okołooperacyjnej karty kontrolnej, zgodnej z założeniami

wypracowanymi przez Grupę Inicjatywną Okołooperacyjnej Karty Kontrolnej przy wsparciu Ministerstwa

Zdrowia.

42 System musi umożliwiać automatyczne tworzenie grafiku zabiegów operacyjnych na podstawie wpisanych

danych. Wydruk grafiku zabiegów w różnych formach: lista, szczegółowy opis zabiegu. Możliwość drukowania

gotowych planów z różnym zakresem danych w różnych komórkach organizacyjnych.

43 System musi umożliwiać definiowanie Sali operacyjnych (z pełnym planowaniem dnia operacyjnego) i

zabiegowych (bez planowania, pozwalających na ewidencję prostych zabiegów).

Strona 67 z 204

44 System musi umożliwiać automatyczne rozliczanie personelu uczestniczącego w zabiegu w systemie

punktowym.

45 System musi umożliwiać współpracę z czytnikami kodów kreskowych i kolektorami danych w zakresie co

najmniej identyfikacji pacjenta po kodzie zamieszczonym na dokumentacji medycznej oraz pracownika po

identyfikatorze osobowym.

46 System musi umożliwiać współpracę z czytnikami kodów kreskowych i kolektorami danych w zakresie

wprowadzenia danych do systemu HIS – dokumentacji pacjenta i ewidencji o zastopowanych lekach, pakietach,

zużytym sprzęcie jednorazowym i materiałach z jednoczesnym połączeniem z modułem apteczki oddziałowej.

47 System musi umożliwiać uzupełnianie opisu zabiegu z poziomu dokumentacji medycznej (oddziału) oraz

możliwość zablokowania jej edycji.

78 System musi umożliwiać automatyczną ewidencję zdarzeń (np. przybycia pacjenta na blok operacyjny i jego

identyfikacji) na podstawie kodu kreskowego.

49 System musi umożliwiać blokowanie edycji fragmentów opisu zabiegu dokonywanych przez poszczególnych

pracowników (np. chirurg, anestezjolog).

50 System musi umożliwiać zdefiniowanie maksymalnego czasu, w którym dozwolony jest opis zabiegu po jego

zakończeniu.

51 System musi umożliwiać zdefiniowanie dopuszczalnych różnic czasu wystąpienia zdarzeń związanych z

zabiegiem. W przypadku przekroczenia tej różnicy użytkownik powinien być uprzedzany o wystąpieniu takiej

sytuacji.

52 System musi umożliwiać definiowaniagruprealizowanychprocedur(np.główne, dodatkowe, anestezjologiczne) i

listy procedur w każdej grupie niezależnie dla każdej Sali operacyjnej.

53 System musi umożliwiać wybór spośród personelu związanego za zabiegiem pracowników przypisanych do

zrealizowanej procedury jako zlecający i wykonujący.

54 System musi umożliwiać ewidencję procedur wykonanych w ramach zabiegu w kosztach funkcjonowania

innych komórek organizacyjnych.

55 System musi umożliwiać zdefiniowanie maksymalnej liczby głównych procedur oraz zablokowania ich edycji.

56 System musi umożliwiać niezależne numerowanie zabiegów:

w księdze bloku (lub Salioperacyjnej),

w księdzeoddziału,

numer kolejny na bloku (lub Salioperacyjnej),

numer kolejny w oddziale.

57 System musi umożliwiać prowadzenie numeracji w księgach:

automatycznej (w momencie zaplanowanie lub przyjęciazabiegu),

automatycznej opóźnionej (zabiegi są wpisywane do księgi po zakończeniu dnia operacyjnego),

ręcznej.

Strona 68 z 204

58 System musi umożliwiać prowadzenie wielu ksiąg zabiegów operacyjnych dla komórki organizacyjnej.

59 System musi umożliwiać wspomaganie planowania dnia operacyjnego:

formularz umożliwiający podgląd zaplanowanychzabiegów,

możliwość edycji w tymformularzu:

- kolejnościzabiegów,

- sali, na której będzie wykonywanyzabieg,

- księgi, jeżeli do wybranej Sali jest przypisanych wieleksiąg,

wykrywaniekonfliktówpodczasplanowaniazabiegów(jednocześniekilkazabiegównatej samej sali

lub personel przypisany jednocześnie do kilku zabiegów),

możliwość przyjmowania zabiegów nieplanowanych(ostrych).

60 System musi umożliwiać ewidencjonowanie zabiegówpołączonych, tzn. osobnych zabiegów chirurgicznych

wykonywanychw ramachjednegoznieczuleniainatejsamejsali(aledotyczącychinnychprocedur i potencjalnie

wykonywanych przez innezespoły).

61 System musi umożliwiać określenie (globalnie lub dla każdej sali operacyjnej) zakresu danych, których

ewidencja jest obowiązkowa przed oznaczeniem zabiegu jako wykonany.

62 System musi umożliwiać automatyczne przenoszenie rozpoznań pooperacyjnych do historii choroby pacjenta wg

konfigurowalnych zasad.

63 System musi umożliwiać definiowanie różnych raportów prezentujących opis zabiegu dla różnych sal

operacyjnych.

64 System musi umożliwiać wygenerowanie raportów dotyczących powtórnych operacji (reoperacji) wykonanych u

tego samego pacjenta dla tego samego pobytu/rozpoznania w ustawionym przez lekarza okresie czasu: dane

chorego, data zabiegu, rodzaj zabiegu, opis zabiegu z protokołu, imię i nazwisko operatora, data reoperacji,

rodzaj zabiegu, opis zabiegu z protokołu, imię i nazwisko operatora, rodzaj powikłania/zagrożenia, przyczyna

wystąpienia, podjęte działania – opis, ocena podjętych działań, miejsce na wprowadzenie wniosków dla

konkretnego przypadku.

65 System musi umożliwiać prowadzenie książki transfuzyjnej zgodnie z rozporządzeniem o leczeniu krwią).

66 System musi umożliwiać zamawianie składników krwi (zgodnie z rozporządzeniem o leczeniu krwią).

67 System musi umożliwiać obsługę zgłaszania zdarzeń niepożądanych (zgodnie z rozporządzeniem o leczeniu

krwią).

68 System musi umożliwiać rejestrację zdarzeń niepożądanych związanych z procedurami zabiegowymi w module

zdarzeń niepożądanych

69 System musi umożliwiać generowanie karty operacyjnej.

70 System musi umożliwiać zamawianie składników krwi bez próby krzyżowej – masywne krwotoki.

71 System musi posiadać pełną integrację z apteczką oddziałową.

Strona 69 z 204

7.1.1.14 Blok Porodowy

Lp. Opis wymagania

1) System musi umożliwiać rejestrację porodu, poród:

na bloku porodowym,

na bloku operacyjnym,

w izbieprzyjęć,

w domu (z pomocą lub bezpomocy),

w innymmiejscu.

2) System musi umożliwiać obsługę położniczej izby przyjęć, pozwalającej na wypełnienie karty wywiadu

położniczego zawierającej odpowiednie dane:

grupa krwimatki,

przeszłość położnicza (informacje o wcześniejszych porodach iporonieniach),

wywiad ogólny (przebyte choroby i operacje, uczulenia, czynniki ryzyka w ciąży, itd.),

wywiad położniczy (przebieg ciąży z podziałem na konfigurowalne pozycje np.:przybranie masy ciała, data

ostatniej miesiączki, tydzień ciąży, pierwsze ruchy płodu, uwagi),

badanie ogólne (z podziałem na konfigurowalne pozycje np.: układ oddechowy, układ krążenia, narządy jamy

brzusznej, układ moczowo-płciowy, budowa ciała i kości, skóra, obrzęki, żylaki, tętno, ciśnienie krwi,

gruczołypiersiowe),

wstępnebadanieginekologiczne(zpodziałemnakonfigurowalnepozycjenp.:krocze,ujście zewnętrzne, ujście

wewnętrzne, część pochwowa, pęcherz płodowy, wodypłodowe),

pomiarmiednicy,

możliwość zdefiniowania dodatkowych pozycjiwywiadu.

3) System musi umożliwiać wydruk wypełnionej karty wywiadu położniczego w izbie przyjęć.

4) System musi umożliwiać ewidencjonowanie godzin pobytu na bloku porodowym, godzin działania znieczulenia.

5) System musi umożliwiać ewidencjonowanie zespołu porodowego (lekarz, położna, anestezjolog, inne wg

konfiguracji).

6) System musi umożliwiać ewidencjonowanie rozpoznania wstępnego oraz rozpoznania po porodzie.

7) System musi umożliwiać ewidencjonowanie typu porodu (bez powikłań, z powikłaniami) i rodzaju porodu

(prawidłowy, szybki, przedłużony) oraz czasu rozpoczęcia i długość faz porodu

8) System musi umożliwiać ewidencjonowanie procedur ICD-9 (główna, dodatkowa).

9) System musi umożliwiać ewidencjonowanie rodzaju znieczulenia zastosowanego podczas porodu.

10) System musi umożliwiać ewidencjonowanie leków i środków medycznych użytych podczas porodu.

11) System musi umożliwiać zlecenie cięcia cesarskiego na bloku operacyjnym i dostęp do danych tego zabiegu.

12) System musi umożliwiać prowadzenie ewidencji porodu – ryzyka porodu:

PrzedwcześnieP.P.P,

poród przedwczesny,

ciąża po terminie - powyżej 42T.C.,

wewnątrzmaciczne obumarciepłodu,

ciążamnoga,

Strona 70 z 204

niewydolność łożyska –podejrzenie,

rzucawka, stanprzedrzucawkowy,

cukrzyca,

łożyskoprzodujące,

przedwczesne oddzieleniełożyska,

inne krwawieniemaciczne,

zespół zakażenia błon jaja płodowego -podejrzenie,

podwyższona ciepłota ciała w czasieporodu,

RH – niezgodność,konflikt,

Hypotrofiapłodu,

nowotwory narządurodnego

możliwość skonfigurowaniainnych.

13) System musi umożliwiać prowadzenie ewidencji porodu - wskazania do rozwiązania operacyjnego:

wady rozwojowe narządurodnego,

stan poe-konizacji,

dystocjaszyjkowa

poprzeczne/skośne położeniepłodu,

położeniemiednicowe,

ułożenie potylicowetylne,

ułożenietwarzyczkowe,

ułożeniewierzchołkowe,

przedłużony poród – zatrzymany w Iokresie,

zatrzymany – przedłużony poród w IIokresie,

wypadnięcie lub przodowaniepępowiny,

zagrażające lub dokonane pęknięciemacicy,

możliwość skonfigurowaniainnych.

14) System musi umożliwiać prowadzenie ewidencji porodu – poród:

stymulacja farmakologicznapłodu,

KTG,

Wodypłodowe,

amnioinfuzja,

pH,

popłód.

15) System musi umożliwiać prowadzenie ewidencji porodu – rodząca:

ilość utraconej krwi wml,

stopień pęknięciakrocza,

Błony płodowe pęknięte > 24h.

16) System musi umożliwiać prowadzenie ewidencji porodu – łożysko: masa[g], nieprawidłowości.

17) System musi umożliwiać wprowadzenie tekstowych opisów: wstępny, porodu, po porodzie.

18) System musi umożliwiać automatyczną ewidencję w systemie danych noworodka wprowadzonego w module Blok

Porodowy:

utworzenie karty pacjenta wypełnionej dostępnymidanymi,

przyjęcie doszpitala,

w przypadku zgonu noworodka lub urodzenia martwego automatyczne wypełnienie karty zgonu.

19) System musi umożliwiać prowadzenie ewidencji danych noworodka:

płeć: męska, żeńska,nieznana,

Strona 71 z 204

masa,

wzrost,

punktacja apgar: 1 minuta, 3, 5 i 10 minut poporodzie

20) System musi umożliwiać rejestrację wieku ciążowego w ocenie: położniczej - pole opisowe, pediatrycznej - pole

opisowe.

21) System musi umożliwiać ewidencjonowanie danych dotyczących ciąży: 1-sza,…n-ta; przebieg ciąży:

powikłany,prawidłowy.

22) System musi umożliwiać ewidencjonowanie danych dotyczących porodu:

1-szy,….,n-ty,

pojedynczy, mnogi,

główkowy: siłami natury, z pomocą ręczną, operacyjny (cięcie cesarskie, kleszcze,Vacuum),

miednicowy: siłami natury, z pomocą ręczną, operacyjny (cięcie cesarskie,kleszcze, Vacuum),

poprzeczny: siłami natury, z pomocą ręczną, operacyjny (cięcie cesarskie,kleszcze, Vacuum),

uwagi – poleopisowe.

23) System musi umożliwiać zlecanie: zabiegów operacyjnych, badań laboratoryjnych i diagnostycznych.

24) System musi umożliwiać konfigurację zakresu ewidencjonowanych danych.

25) System musi umożliwiać identyfikowanie noworodka urodzonego w szpitalupoprzez wydruk dwóch opasek

dlanoworodka

26) System musi umożliwiać bezpośrednie zlecanie cięcia cesarskiego i dostępu do danych odpowiedniego zabiegu na

bloku operacyjnym.

27) System musi umożliwiać tworzenie następujących raportów:

wykaz porodów,

wykaz noworodków,

wykaz poronień,

wykaz przerwań ciąży i zgonów kobiet,

wykaz cięć cesarskich.

28) System musi umożliwiać prowadzenie książki transfuzyjnej zgodnie z rozporządzeniem o leczeniu krwią.

29) System musi umożliwiać zamawianie składników krwi (zgodnie z rozporządzeniem o leczeniu krwią).

30) System musi umożliwiać generowanie sprawozdania o ilości porodów, urodzeń i zgonów noworodków.

31) System musi umożliwiać obsługę zgłaszania zdarzeń niepożądanych (zgodnie z rozporządzeniem o leczeniu krwią).

7.1.1.15 Bank krwi -zlecenia

Lp. Opis wymagania

1. System musi umożliwiać zlecanie zapotrzebowań do banku krwi na krew i preparaty krwiopochodne, zlecenie

przejmuje elektronicznie moduł Bank Krwi.

2. System musi umożliwiać podgląd wszystkich zaewidencjonowanych dla pacjenta zapotrzebowani na preparaty

krwiopochodne.

Strona 72 z 204

3. System musi umożliwiać podgląd szczegółowych informacji zebranych podczas wywiadu.

4. System musi umożliwiać ewidencję danych dotyczących preparatu krwiopochodnego:

Nazwapreparatu,

czynnik RhD,

usługi wymagane przy podaniupreparatu,

ilość i jednostkamiary,

lekarz zlecający podaniepreparatu,

wskazanie dotransfuzji.

5. System musi umożliwiać zlecenie w trybie zwykłym oraz w trybie cito.

6. System musi umożliwiać wydruk zlecenia.

7. System musi umożliwiać wydruk skierowania na konsultację do RCKiK.

8. System musi umożliwiać zaewidencjonowanie informacji o typie biorcy.

9. System musi umożliwiać zaewidencjonowanie informacji o dacie ostatniego przetaczania krwi.

10. System musi umożliwiać automatyczną numerację zapotrzebowań na preparaty krwiopochodne.

11. System musi umożliwiać wydruk skierowania na próbę zgodności.

12. System musi umożliwiać automatyczne wystawienie skierowania do laboratorium.

13. System musi umożliwiać prowadzenie książki transfuzjologicznej w wersji elektronicznej

14. System musi umożliwiać automatyczne przekazanie do modułu KKL danych o wartości zużytej krwi na pacjenta

7.1.1.16 Zakażenia szpitalne

Lp. Opis wymagania / punktacja

1. System musi umożliwiać zgłoszenie podejrzenia zakażenia zarówno z poziomu oddziału jak i poradni

(Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

2. System musi umożliwiać podgląd wykazu zakażeń dostępny m.in. z poziomu oddziału.

3. System musi umożliwiać stworzenie karty zakażenia personelu.

4. System musi umożliwiać wyświetlanie alertu o możliwości zakażenia w przypadku zmian wybranych parametrów

np. przy temperaturze ciała powyżej 38 st. C.

5. System musi umożliwiać kontrolę tworzenia i akceptacji kart zakażeń oraz kart drobnoustrojów alarmowych przez

wykwalifikowany zespół kontroli zakażeń.

6. System musi umożliwiać monitorowanie przebiegu zakażenia przez cały okres jego utrzymywania się.

7. System musi umożliwiać ewidencjonowanie ognisk epidemicznych.

8. System musi umożliwiać tworzenie dokumentów ZLK 1-5 z poziomu oddziału, zgodnie z rozporządzeniem

Ministra Zdrowia.

Strona 73 z 204

9. System musi umożliwiać podgląd listy wszystkich podejrzeń zakażeń wraz z odniesieniem do dokumentu

źródłowego.

10. System musi umożliwiać tworzenie zestawień sprawozdawczych oraz analitycznych, np.: rejestr zakażeń, statystyka

zakażeń, mapa mikrobiologiczna, rejestr dokumentów ZLK, zestawienia rodzajów i miejsc wystąpienia zakażenia z

podziałem na jednostkę i czas.

11. System musi umożliwiać generowanie własnych raportów dotyczących zakażeń z danych wprowadzonych w

systemie.

12. System musi umożliwiać podgląd danych:

wszystkich pacjentów

pacjentów na wybranym oddziale

pacjentów z karta zakażeń

pacjentów z drobnoustrojem alarmowym

pacjentów z dokumentami powiązanymi z zakażeniem.

13. System musi umożliwiać włączenie automatycznej podpowiedzi o możliwym podejrzeniu zakażenia w

następujących przypadkach:

temperatura pacjenta wyższa niż 38 st.C

ocena stolca: biegunka, płynny i z krwią

obserwacja wkłucia obwodowego: ropna wydzielina, zaczerwienienie miejsca wkłucia kaniuli

obserwacja miejsca operowanego: zaczerwienienie, wysięk ropny

obserwacja wkłucia centralnego: zaczerwienienie, obrzęk, ból

możliwość automatycznego utworzenia karty podejrzenia zakażenia podczas tworzenia karty drobnoustroju

alarmowego.

14. System musi umożliwiać realizację karty zakażenia:

rozpoznanie zakażenia

czynniki wpływające na zakażenie podczas pobytu w szpitalu

rodzaj zakażenia

podjęte czynności lecznicze i prewencyjne

podania leków

wykonane operacje

badanie mikrobiologiczne

kwalifikacja zakażenia.

15. System musi umożliwiać uzupełnianie karty zakażenia fragmentami, z możliwością powrotu do wybranych

zakładek.

16. System musi umożliwiać stworzenie ogniska epidemicznego

raport wstępny

raport końcowy

przypisane karty zakażenia do ogniska

automatyczne wyliczanie liczb ognisk na podstawie zakażeń

wydruk raportu wstępnego i okresowego.

17. System musi umożliwiać zarządzanie drobnoustrojami alarmowymi poprzez rejestrację i czynniki prewencyjne

18. System musi umożliwiać dodanie dokumentów związanych z zakażeniem:

ZLK1 - choroba zakaźna

ZLK2 - gruźlica

ZLK3 - płciowe

ZLK4 - ADIS/HIV

Strona 74 z 204

ZLK5 - zgon

ocena ryzyka nabycia zakażenia przy przyjęciu do szpitala.

19. System musi umożliwiać zbiorczą modyfikacji kart zakażeń i kart drobnoustroju alarmowego.

20. System musi umożliwiać wygenerowania raportów:

Czynniki ryzyka analiza

Mapa mikrobiologiczna

Monitorowanie czynników ryzyka

Rejestr dokumentów ZLK

Rejestr kart patogenów alarmowych

Rejestr kart zakażeń

Statystyka zakażeń

Wykaz biologicznych czynników chorobotwórczych

Zestawienie kwalifikacji zakażeń

Zestawienie liczby kart zakażeń

Zestawienie liczby zakażeń(czas/jednostki)

Zestawienie miejsc wystąpienia zakażeń (czas/jednostki)

Zestawienie rodzajów zakażeń (jednostki).

21. System musi umożliwiać wspieranie identyfikacji pacjentów o wysokim poziomie zagrożenia zakażeniem przez

definiowanie dowolnych warunków wyboru pacjentów uwzględniających wpisy w historii choroby pacjenta.

22. System musi umożliwiać prowadzenie rejestru wszystkich zakażeń wewnątrzszpitalnych.

23. System musi umożliwiać nanoszenie wszystkich niezbędnych danych do wypełnienia Karty Zakażenia Szpitalnego.

Dane ewidencjonowane w innych modułach pojawiają się automatycznie.

24. System musi umożliwiać ewidencjonowanie zgłoszeń zakażeń na oddziale.

25. System musi umożliwiać zaewidencjonowania dla jednego pacjenta dowolnej liczby kart w ramach jednego pobytu

na oddziale.

26. System musi umożliwiać odbieranie kart zgłoszenia zakażenia szpitalnego przez zespół kontroli zakażeń

zakładowych jako indywidualne karty rejestracji.

27. System musi umożliwiać odnotowanie kwalifikacji zakażeń z podziałem na szpitalne i pozaszpitalne.

28. System musi umożliwiać prowadzenie analiz liczbowych i procentowych danych z Kart Zakażeń Szpitalnych z

podziałem na szpitalne i pozaszpitalne:

kwalifikacja zakażenia,

czas do pierwszych objawów zakażenia,

przebieg kliniczny,

czas leczenia,

powód przyjęcia,

skąd przyjęty,

czas poprzedniej hospitalizacji,

płeć,

wiek,

rozpoznanie zakażenia,

rodzaj zakażenia,

czynniki ryzyka.

29. System musi umożliwiać nanoszenie niezbędnych danych w odniesieniu do chorych poddawanych zabiegom

operacyjnym (dane ewidencjonowane w module blok operacyjny pojawiają się automatycznie):

Strona 75 z 204

długość pobytu przed operacją,

czas od zranienia,

rodzaj operacji (nagła, planowa),

stopień czystości pola operacyjnego,

czas trwania operacji,

rodzaj znieczulenia,

profilaktyka przeciwbakteryjna,

miejsce operacji,

techniki operacyjne,

drenaż z uwzględnieniem jego rodzaju,

nr katalogowy operacji,

rodzaj zakażeń dla operowanego,

antybiotykoterapia,

badania mikrobiologiczne i antybiogram.

30. System musi umożliwiać tworzenie szablonów dokumentów wykorzystywanych w komórce zakażeń szpitalnych.

31. System musi umożliwiać dostęp do rejestru i wyników badań bakteriologicznych.

32. System musi umożliwiać zatwierdzanie przez lekarza odpowiedzialnego za rejestr zakażeń szpitalnych kart

spływających z poszczególnych oddziałów i uwzględniania ich w raportach.

33. System musi umożliwiać dwuetapowe zatwierdzania karty: wstępnej weryfikacji przez jedną osobą

i ostatecznego zatwierdzenia przez inną.

34. System musi umożliwiać dostępdodanychzcałegosystemu(mechanizmwartościpoczątkowychpólkartyoraz

dowiązywania formularzy należących do innych modułów).

35. System musi umożliwiać ocenę ryzyka powstawania odleżyn.

36. System musi umożliwiać generowanie dowolnych raportów z zakresu tematyki zakażeń szpitalnych.

37. System musi umożliwiać dostęp do wyników antybiogramów.

38. System musi umożliwiać dostęp do wykazu zużycia antybiotyków na poszczególnych oddziałach w przeliczeniu na

jednostki mocy (dawki), DDD, opakowania i inne.

39. System musi umożliwiać wygenerowane raportu z pacjentami z wybranej grupy ryzyka oraz pacjentów

spełniających warunki do pobrania badania przesiewowego (przypadki zostaną opisane w przesłanej ocenie ryzyka).

40. System musi umożliwiać numerację kart zakażeń oraz kart patogenów alarmowych niezależna dla każdego

oddziału: numer/kod oddziału/rok.

41. System musi umożliwiać - określenie podstawy podania antybiotyków: profilaktyka okołooperacyjna, profilaktyka

medyczna, leczenie zakażenia, inne + opis. Na podstawie podań leków analiza przyczyn podawania leków. Terapia

empiryczna, celowana, itd.

42. System musi umożliwiać podgląd w moduł zakażenia przy przyjmowaniu pacjenta do szpitala oraz na oddziale

pacjenta, u którego wcześniej wystąpiło zakażenie szpitalne lub wykryto patogen alarmowy.

43. System musi umożliwiać wyświetlanie alertu o możliwości zakażenia w przypadku zmian wybranych parametrów:

w przypadku wystąpienia podejrzenia zakażenia (podwyższona temperatura ciała, obserwacje wkłuć, cewników,

miejsc operowanych) przy wypełnianiu dokumentów przez lekarza konieczność weryfikacji podejrzenia zakażenia.

44. System musi umożliwiać automatyczne uzupełnianie o wyniki z pracowni bakteriologii: W czasie tworzenia karty

zakażenia szpitalnego lub patogenu alarmowego wykorzystanie wyników badań mikrobiologicznych z systemu

Strona 76 z 204

laboratoryjnego.

45. System musi umożliwiać wygenerowania zlecenia z tego modułu na badania do pracowni mikrobiologicznej -

środowiskowe i powietrza tzn. wymazy, posiewy, które pobierane są przez Zespól zakażeń. System powinien

również zapewnić podgląd w tym module uzyskanych wyników badań: Zlecenia badań mikrobiologicznych –

określenie podstawy wykonywania badania: badanie epidemiologiczne (dot. Środowiska), badanie kliniczne,

badanie przesiewowe.

7.1.1.17 Zlecenia i skierowania

Lp. Opis wymagania

1. System musi umożliwiać tworzenie elektronicznych zleceń badań (w tym laboratoryjnych) kierowanych do

jednostek wykonujących w ramach struktury organizacyjnej Zamawiającego, śledzenie statusu zleceń i dostęp do

wyników powstałych wskutek realizacji zleceń, przy czym do czasu uruchomienia funkcjonalności zleceń

elektronicznych system zapewni możliwość ewidencji papierowych wersji zleceń i skierowań oraz możliwość

wydruku wszystkich zleceń i skierowań do jednostek wykonujących w ramach struktury organizacyjnej

Zamawiającego.

2. System musi umożliwiać ewidencję i drukowanie skierowań do instytucji zewnętrznych tj. skierowanie na

hospitalizację, skierowanie do sanatorium, skierowanie na badania wykonywane poza jednostką Zamawiającego,

zgodnie z wymogami prawa.

3. System musi zapewniać możliwość rejestrację zleceń i skierowań z jednostek organizacyjnych Zamawiającego z

dokładnością do osoby zlecającej oraz zleceń z podmiotów zewnętrznych zgodnie z obowiązującymi wymogami.

4. System musi umożliwiać przygotowanie skierowań na badania złożone, kierowane do zewnętrznych jednostek.

Przykładem badania złożonego może być skierowanie na badania laboratoryjne obejmujące kilka parametrów

badanych np. morfologia, OB., analiza moczu.

5. System musi zapewniać automatyczne przekazywanie wersji elektronicznych zleceń do odpowiedniej komórki

organizacyjnej realizującej.

6. System musi informować zlecającego o wszystkich zleconych i wykonanych badaniach zarówno z bieżącej jak i

innych jednostek organizacyjnych Zamawiającego, dotyczących sytuacji, gdy w zadanym (opcjonalnie) okresie

czasu pacjent miał już zaewidencjonowane takie samo zlecenie.

7. System musi zapewniać blokowanie edycji zlecenia po jego zatwierdzeniu i wysłaniu.

8. System musi zapewniać możliwość anulowania zlecenia przed jego realizacją.

9. System musi rejestrować i prezentować uprawnionym użytkownikom etap wykonania, na jakim znajduje się

zlecenie (zlecone, w trakcie realizacji, odwołane, zrealizowane, inne - stosownie do potrzeb).

10. System musi zapewniać autoryzację wprowadzonych zleceń (automatyczną i wymagającą potwierdzenia ze strony

zlecającego) oraz udostępniać narzędzia do przeglądu tych autoryzacji.

11. System musi zapewniać możliwość wykorzystania danych dotyczących zleceń do rachunku kosztów i wyceny

procedur medycznych.

12. System musi prowadzić ewidencję daty i godziny dokonania operacji: wprowadzenie, zmiany, anulowanie

realizacji zlecenia, wprowadzanie zmiany wyniku, udostępnienie (autoryzacji) wyniku oraz danych

identyfikacyjnych użytkowników realizujących te operacje.

13. System musi zapewniać możliwość realizacji zleceń na podstawie listy zleceń (umożliwiającej przegląd zleceń

Strona 77 z 204

według daty i rodzaju zlecenia), zawierającej wszystkie niezbędne dane, wykluczając konieczność wyszukiwania

pacjenta lub wizyty.

14. System musi zapewniać możliwość przeglądania i edycji danych zawartych w zarejestrowanym zleceniu, stosownie

do posiadanych przez użytkownika uprawnień.

15. System musi zapewniać możliwość odnotowania realizacji całego zlecenia jak i jego określonej części.

16. System musi udostępniać wyniki zrealizowanych zleceń (np. wynik badania) zlecającemu i uprawnionym

użytkownikom.

17. System musi zapewniać uprawnionym użytkownikom możliwość podglądu wyników badań pacjenta: z

konkretnych zleceń, z konkretnej pracowni, wszystkich wyników pacjenta.

18. System musi zapewniać możliwość ewidencjonowania i wystawiania zleceń w zakresie zaopatrzenia w przedmioty

ortopedyczne i środki pomocnicze zgodnie z obowiązującymi zasadami prawa.

19. System musi zapewniać możliwość realizacji zleceń co najmniej w Pracowniach, Poradniach, Rejestracjach,

Oddziałach, Działach

20. System musi zapewniać możliwość integracji systemu HIS z systemami typu RIS/PACS w zakresie:

a. elektronicznego wysyłania zleceń do RIS,

b. automatycznego odbioru wyniku (opisu) zleconego badania,

c. automatycznego odbioru statusu badania,

d. automatycznego przypisanie kodu ICD-9 wykonanej procedurze, generowanie usług NFZ w powiązaniu z

procedurą ICD-9.

21. System musi zapewniać możliwość planowania i zlecania badań diagnostycznych i laboratoryjnych, zabiegów,

konsultacji w ramach zleceń wewnętrznych (przekazywanych pomiędzy komórkami organizacyjnymi

Zamawiającego):

1. z Oddziału do Pracowni i Działów Diagnostycznych

2. z Oddziału do Poradni, Oddziału,

3. z Oddziału do Bloku operacyjnego,

4. z Poradni, Gabinetu do Oddziału, Pracowni i Działów Diagnostycznych oraz Pracowni Rehabilitacji

5. z Bloku operacyjnego do Oddziału, Pracowni, Poradni i Działów Diagnostycznych

6. System powinien zapewniać możliwość planowania i zlecania badań i konsultacji w ramach zleceń

zewnętrznych

(z innych podmiotów):

7. w Poradniach,

8. w Pracowniach,

9. w Laboratorium.

22. System musi zapewniać zlecanie badań do systemów podrzędnych np. RIS/PACS, LIS przy wykorzystaniem

standardu HL7.

23. System musi zapewniać możliwość definiowania zleceń złożonych np. na zestaw badań

24. System musi zapewniać możliwość przegląd zleceń według ustalonych przez użytkownika kryteriów np.: dla

pacjenta, typu zlecenia (np. laboratoryjne, diagnostyczne, podanie leku).

25. System musi zapewniać możliwość wydruku zleceń.

26. System musi zapewniać możliwość przeglądanie dzienne zestawienie badań do wykonania.

27. System musi zapewniać możliwość wydruku wszystkich wyników pacjenta z bieżącej hospitalizacji lub ze

wszystkich pobytów w szpitalu.

Strona 78 z 204

28. System musi zapewniać możliwość przeglądu wszystkich zleceń z jednostki zlecającej z możliwością wydruku

wyniku.

29. System musi zapewniać możliwość ewidencji danych niezbędnych dla sporządzenia karty gorączkowej.

30. System musi zapewniać możliwość przeglądu karty gorączkowej, prezentacji interpretacji graficznej wyników.

31. System musi zapewniać możliwość zapisania indywidualnych pakietów badań.

32. System musi zapewniać możliwość zapisania pakietów zleceń z poziomu administracyjnego wszystkim

pracownikom danej komórki organizacyjnej.

33. System musi zapewniać możliwość zapisywania podręcznych pakietów badań pogrupowanych

34. System musi umożliwiać uzupełnianie uwag/powodu zgłoszenia do zlecenia.

35. System musi umożliwiać zapisywanie szablonów w polach opisowych w zleceniu badań.

36. System musi umożliwiać zapisanie jako szablon dokumentu zlecenia ze wszystkimi danymi zapisanymi w zleceniu.

37. System musi zapewniać możliwość edycji zapisanych wcześniej pakietów badań.

38. System musi zapewniać możliwość anulowania zlecenia po jego zapisaniu.

7.1.1.18 Apteka szpitalna

Lp. Opis wymagania

- Program powinien zabezpieczać bieżącą pracę Apteki Szpitalnej, gwarantować zabezpieczenie wymogów NFZ i

obowiązującego Prawa Farmaceutycznego i Ustawy o Wyrobach Medycznych Dyrektywy unijnej 2011/62/EU tzw.

dyrektywy fałszywkowej i implementacji jej do polskiego prawa. W szczególności musi gwarantować gospodarkę

materiałową. Dodatkowe szczególne wymogi:

- wprowadzanie faktur w tym faktury z recepturą (precyzja do minimum 4 miejsc po przecinku).

- podział asortymentu wprowadzanego z faktury na grupy towarowe np. leki (antybiotyki, płyny), opatrunki i

inne wyroby medyczne, możliwość zgrywania z nośników elektronicznych

- identyfikowanie danej grupy towarowej na wydruku PZ.

- na wydruku PZ przypisanie do danej pozycji nr umowy przetargoweji faktury,

- blokowanie wydania danego asortymentu z magazynu na poziomie wprowadzania faktury np. zła cena

produktu

- możliwość poprawiania ceny lub ilości przy danej pozycji wprowadzonego produktu, wydruk PZ nie

zmienia kolejności wprowadzonych produktów a następnie korygowanych

- możliwości prowadzenia różnorodnych analiz zakupów np. analiza zakupów wg. Umowy przetargowej i jej

rozliczenie

- przypisanie do danej pozycji umowy przetargowej (możliwe dwie zazębiające się umowy)

- rozliczanie umów przetargowych

- aktualizacja bazy leków

- baza zamienników danego leku, baza leków z nazwą producenta oraz nazwą międzynarodową substancji

czynnie działającej

- Obrót magazynowy. Wydawania na apteczki oddziałowe leków i innych materiałów.

Dodatkowo:

- wykorzystanie słowników produktów leczniczych, grup ATC- (z możliwością dowolnej konfiguracji

od poziomu 1 do 7) oraz nazw międzynarodowych

Strona 79 z 204

- definiowania własnych grup asortymentu (globalne i lokalne) dot. produktów leczniczych i wyrobów

medycznych.

- definiowanie własnych wydzielonych magazynów

- tworzenie lokalnych słowników produktów leczniczych i wyrobów medycznych dla magazynów

- wyszukiwania produktu leczniczego na podstawie kodu EAN, PC, GTIN, nazwy międzynarodowej i

handlowej

- rezerwacja stanów magazynowych

- bieżąca korekta jakościowa stanów magazynowych na podstawie dokumentu korygującego

- odnotowanie wstrzymania, wycofania lub dopuszczenia leku wg, komunikatów GIF, skutkujące

alertem i wstrzymaniem wycofanego/wstrzymanego leku na poziomie preskrypcji lekarskiej i realizacji

zleceń pielęgniarskich

- przegląd stanów magazynowych bieżących oraz na wybrany dzień wraz ze stanami zerowymi, po

nazwie międzynarodowej oraz handlowej

- umożliwienie weryfikacji przekroczenia procentowego limitu ustawionego dla magazynu

- kontrola dat ważności oraz możliwość zdejmowania ze stanu leków przeterminowanych (wzór

dokumentu zgodny z PF)

- definiowanie własnych dokumentów (np. przyjęcie próbek, )

- numerowanie dokumentów wg własnych definiowanych wzorców

- możliwość blokowania w magazynie wydawania danej pozycji np. lek wstrzymany lub wycofany z

obrotu.

- wszystkie możliwe analizy np. rozchodów danej pozycji danej grupy towarowej, lub wg umowy

przetargowej, możliwość tworzenia własnych analiz

- remanenty – np. na dzień, miesiąc

- zestawiania kosztów –analizy – różne warianty, możliwość tworzenia własnych analiz

- dostępne analizy magazynowe powinny być możliwe do wykonania „na dzień” (wartości pokazywane

na wybrany dzień w przeszłości).

- wyróżnianie kolorami leków i materiałów znajdujących się w Receptariuszu Szpitalnym oraz spoza

niego. Możliwość tworzenia widoków na stany po takich samych parametrach.

- Sporządzanie zamówień:

1. do dostawców na podstawie aktualnych stanów magazynowych, stanów minimalnych i maksymalnych, z tzw.

zamówień doraźnych ściśle powiązanych z dokumentem wydania na oddział.

2. blokada zamówienia , kiedy umowa jest całkowicie zrealizowana lub wykorzystana jej wartość lub jest

niezatwierdzona

3. dokument zamówienia winien mieć możliwość dopisania ważnych elementów (np. cito) oraz winien

pokazywać numer umowy.

- Ewidencja dostaw:

- dostawa od Kontrahenta wprowadzania jest drogą elektroniczną, z dodatkową funkcjonalnością i

możliwością zaciągnięcia e-faktury z platformy

- wprowadzenie faktury poprzez funkcję realizacji zamówienia od dostawcy

- możliwość zaciągnięcia faktury z systemu KOWALA jeśli będzie to możliwe, podczas operacji

sprawdzenia

- manualna rejestracja faktury przychodowej z możliwością przypisania zamówienia do faktury

- import docelowy, dokument przychodowy z możliwością uzupełnienia elementów zgodnych z Prawem

Farmaceutycznym ( między innymi pozwolenie MZ, kraj pochodzenia produktu itp..)

- dokument przychodu próbek winien mieć możliwość rejestracji danych osoby dostarczającej oraz nazwę

podmiotu odpowiedzialnego.

- ewidencja dostaw na podstawie kodu EAN, GTIN, PC. W przypadku braku pozycji o podanym kodzie

system powinien bezpośrednio na etapie przyjęcia, ze słownika zewnętrznego zaciągnąć dane z bazy

BAZYL lub BLOZA lub innego równoważnego.

- korekta dokumentów ewidencjonująca dostawy produktów leczniczych i wyrobów medycznych

- modyfikacja dokumentów dostawy między innymi w zakresie korekty części dostawy

- dokument przychodowy PZ zawiera ponadto informację dot. realizację umowy:

z jakiej umowy, z jakiego postępowania, wartość umowy, ilość zrealizowana i stan umowy po

zatwierdzeniu zakupu.

Strona 80 z 204

- system zintegrowany jest z czytnikami kodu mozaikowego i paskowego (zgodnie z obowiązującymi

przepisami)

- dokumenty przychodowy tzw. PZ mają możliwość zmian w stopce dokumentu

- Ewidencja wydań:

- system umożliwia realizację zleceń z oddziałów, winien uwzględniać zlecenia na pacjenta w dowolnej

grupie asortymentowej

- system umożliwia wydanie leku indywidualnemu pacjentowi np. do domu (program lekowy) lub do innej

jednostki organizacyjnej (świadczenie usługi dla innego szpitala

- wydanie na oddziały za pomocą dokumentów RW oraz MM na podstawie zamówień elektronicznych lub

papierowych (oprócz apteczek oddziałowych inne jednostki szpitala)

- ewidencja wydań na podstawie kodów EAN, GTIN, PC, nazw międzynarodowych i handlowych

- możliwość elektronicznego potwierdzenia realizacji zamówienia z oddziału

- możliwość wydania na zewnątrz jednostki szpitala

- możliwość korekty zwrotów do dostawców

- korekta ubytków i strat

- korekta wydań produktów leczniczych i wyrobów medycznych

- kontrola i definiowanie limitów wartościowych produktów leczniczych i wyrobów medycznych

wydawanych na oddział

- możliwość prezentacji wartości w postaci ułamkowej lub co najmniej do czterech miejsc po przecinku

- dokumenty RW oraz MM winny mieć możliwość dowolnej konfiguracji stopki

- analiza interakcji pomiędzy składnikami leków wydanych dla pacjenta, informacja na podst. BAZYL,

BLOZ lub inne równoważne

- System winien umożliwiać definiowanie zamienników dla wybranych produktów leczniczych

- system winien posiadaćmożliwość przypisania produktu leczniczego do grupy zamienników.

- Inwentaryzacja

- generowanie arkusza ze spisu z natury

- korekta stanów magazynowych (ilościowa i jakościowa) na podstawie arkusza ze spisu z natury z

dokładnością do dostawy lub asortymentu

- system winien sprawdzać, czy występują różnice remanentowe wraz z informacją o braku różnicy

remanentowej

- system winienumożliwiać dopisanie do spisu z natury pozycji dla których nie odnotowano obrotów w

danym magazynie.

- dokument inwentaryzacji spisu z natury winien umożliwiać wpisanie Komisji- wielopozycyjny

- Zamówienia publiczne

- wspieranie obsługi zamówień publicznych

- przekazywanie list asortymentowej- wartościowej do modułu zamówień i przetargów

- kontrola realizacji dostaw i poziomu cen umów najlepszej oferty- umowy) szczególnie na poziomie

realizacji (jw.)

- raporty po numerze umowy i postępowaniu przetargowym

- wyszukiwanie z umowy po nazwie międzynarodowej i handlowej i EAN

- widoczne okna z wartościami netto i brutto danej umowy

- generowanie procentowego zużycia dla dowolnej umowy, ilości umów.

- automatyczna blokada lub inna widoczna informacja np. status, kiedy umowa zakończona lub

wykorzystana lub niezatwierdzona

- Receptura

1. system musi posiadać możliwość generowania dokumentów do sporządzania leków recepturowych z

danymi zgodnymi z PF oraz FP XI- tj. więcej pól do wypełnienia przy każdym wytwarzaniu leku-

producent, warunki przechowywania, opis czynności, itp.

- Cytostatyki i żywienie pozajelitowe

Strona 81 z 204

2. realizacja zamówień z Oddziałów

3. możliwość integracji w przyszłości z poziomu HIS z ew. systemami do przygotowywania żywienia

pozajelitowego oraz cytostatyków

- Raporty i zestawienia

1. na podstawie rozchodów, przychodów, stanów magazynowych po ATC(zakres dla DDD od 1-7), po

umowie(numerze umowy i postępowaniu), po grupach analitycznych, po rodzajach dokumentów, po

kontrahencie, po jednostce organizacyjnej po dostawcy, po producencie, po grupie analitycznej i po grupie

farmaceutycznej,

2. możliwość wydruków do plików PDF oraz XLS

3. możliwość generowania raportów wg własnych definiowanych potrzeb

4. generowanie zamówień wewnętrznych

5. eksport danych do Księgowości: przychody , rozchody, różnice wartościowe, obroty z kontrahentami

- Integracja z modułem księgowym

1. zapewnienie dostępności funkcji wartościowego, syntetycznego zapisu obrotu materiałowego na

odpowiednich kontach

2. możliwość zapisu dokumentów rozchodowych(koszty) na poziomie wydania z apteki

3. możliwość zapisu dokumentów rozchodowych (koszty) na poziomie wydania z magazynu apteczki

oddziałowej

4. możliwość eksportu dokumentów rozchodu wewnętrznego w odpowiednim formacie

- ZSMOPL

- system posiada pełna funkcjonalność wraz z połączeniem odpowiedniej platformy z w ramach systemu

ZSMOPL

- karty leków automatycznie posiadają zadane informacje o konieczności przesłania do ZSMOPL

- KOWAL

- system posiada pełna funkcjonalność połączenia z KOWALem, na etapie przyjęcia towaru (j.w) i wydania

na oddział(j.w)

- Farmakoterapia

- przechowywanie informacji o leku

- decyzje GIF, wstrzymanie , wycofanie i dopuszczenie- przesyłanie na oddziały

- działania niepożądane(NDL, NOP)- ewidencja

- definiowanie receptariusza szpitalnego- możliwość generowania do pliku csv.

- Depozyty (komis)

- System posiada oddzielny moduł magazynu depozytowego

- przyjmuje depozyt np. wg WZ

- po wszczepie generuje zamówienie do firmy celem uzupełnienia depozytu- generowanie zamówienia.

Blokada zamówienia w przypadku przekroczenia wartości umowy

- przyjmuje fakturę depozytową, na dokumencie PZ winna znaleźć się informacja o numerze umowy,

numerze postępowania wartości umowy, wartości zrealizowanej umowy oraz po zatwierdzenie ile

pozostało z umowy.

- rozchodowuje depozyt na pacjenta - ścisły związek dostępu CBO do listy pacjentów (PESEL lub nazwisko

lub numer historii choroby)

- rozchodowuje depozyt bez pacjenta

- koryguje rozchód depozytowy

- tworzenie zamówienia do firmy bez pacjenta

- umożliwia kontrolę zamówień do dostawców

- kontroluje umowy przetargowe depozytowe informując o stopniu realizacji

Strona 82 z 204

- Integracja z systemem szaf lekowych

1. System musi umożliwiać w przyszłości integrację ze szpitalnym systemem w przypadku uruchamiania i

wdrażania systemu UNIT DOSE

2. System musi umożliwiać w przyszłości integrację ze szpitalnym systemem w przypadku uruchamiania i

wdrażania systemu szaf RFID lub SZAF LEKOWYCH

7.1.1.19 Apteczka oddziałowa

Lp. Opis wymagania

1. System musi umożliwiać generowanie zamówień do Apteki Szpitalnej

2. System musi umożliwiać dołączenie do zamówienia informacji nt. pacjenta, dla którego dany lek jest zamawiany.

3.

System musi umożliwiać wydawania środków farmaceutycznych z apteczki oddziałowej:

1. wydawanie na oddział lub na pacjenta,

2. zwrot do apteki,

3. ubytki i straty nadzwyczajne.

4.

System musi umożliwiać wprowadzanie korekt stanów magazynowych:

1. korekta stanów magazynowych (ilościowa i jakościowa) na podstawie arkusza spisu z natury,

2. generowanie arkusza do spisu z natury.

5.

System musi zapewniać wspomagania decyzji farmakoterapeutycznych:

1. pomoc w zakresie tworzenia i zarządzania receptariuszem szpitalnym,

2. informacja o leku, (postać, dawka, wielkość opakowania, dostępność/brak w receptariuszu szpitalnym, inne leki

dostępne z tej grupy (zamienniki dla danego leku), dostępność na podstawie odrębnej decyzji osób

odpowiedzialnych za dystrybucję na terenie szpitala itd. – cena ostatniej dostawy.

6. System musi umożliwiać wykonywanie czynności analityczno-sprawozdawczych, tworzenie bieżących raportów i

zestawień.

7. System musi umożliwiać podział leków na wydawane na oddział lub na pacjenta.

8. System musi umożliwiać wykorzystanie słowników (również dla celów wyszukiwania): leków, grup ATC, nazw

międzynarodowych, słownik jednostek miar itp. jak też kolory do oznaczania laków z Receptariusza.

9. System musi umożliwiać kontrolę dat ważności oraz możliwość zwracania leków przeterminowanych do

magazynów/apteki.

10. System musi umożliwiać pełny dostęp do danych archiwalnych.

11. System musi umożliwiać prowadzenie dziennika akcji wykonanych w systemie (logi).

12. System musi umożliwiać definiowanie i obsługę wielu apteczek oddziałowych w ramach jednego oddziału.

13. System musi umożliwiać ewidencjonowanie i obsługę przyjęć leków własnych pacjenta.

14. System musi umożliwiać ewidencjonowanie zużycia leków i materiałów medycznych na pacjenta z jednej oraz z

wielu apteczek i automatyczne przeniesienie danych do modułu KKL.

15. System musi umożliwiać ewidencjonowanie zużycia na oddział z jednej oraz z wielu apteczek, a dalej automatyczne

Strona 83 z 204

przeniesienie danych do modułu kosztów.

16. System musi umożliwiać przeprowadzenie inwentaryzacji w apteczce.

17. System musi umożliwiać przegląd i kontrolę stanów magazynowych oraz obrotów w magazynkach oddziałowych.

18. System musi umożliwiać przygotowanie i wydruk arkuszy spisowych magazynków oddziałowych wg grup i

indeksów oraz innych parametrów indeksu (podobnie jak w Aptece)

19.

Moduł powinien posiadać możliwość wykonania zestawień:

1. zużycia środków farmakologicznych z podziałem na płatników,

2. zużycia środków farmakologicznych na pacjenta.

Także na wskazany dzień w przeszłości.

20. System musi umożliwiać przeprowadzenie spisu z natury.

21. System musi umożliwiać przeprowadzenie inwentaryzacji z poziomu apteczki oraz apteczki dyżurki pielęgniarek.

22. System musi umożliwiać wypełnienie, wydruk karty zgłoszenia niepożądanego działaniu produktu leczniczego

(NDL, NOP) z jednoczesnym wpisaniem zdarzenia do modułu zdarzeń niepożądanych.

23.

System musi umożliwiać wydruk następujących raportów:

Stanu leków i materiałów po różnych grupach i innych parametrach indeksu,

Przyjęcieśrodków,

doniesienie o niepożądanym działaniuśrodka leczniczego,

książka kontroli przychodów irozchodów,

zestawienie zużycia środków przez pacjentów naoddziale,

zestawienie zużycia środków przezpacjenta,

zapotrzebowanie na środki doapteczki,

dokument zwrotu środków doapteki,

kasacja środków naoddziale,

lista leków ze zbliżającym się końcem daty ważności,

Wszystkie raporty muszą pozwalać na pokazywanie stanu na wybrany dzień także w przeszłości.

24. System musi umożliwiać generowanie raportu Jednorodnego Pliku Kontrolnego na wezwanie Urzędu Skarbowego

dla wskazanego magazynu.

25. System musi posiadać precyzję cen opakowań rejestrowanych w bazie z dokładnością co najmniej 5 miejsca po

przecinku.

26. System musi umożliwiać blokowanie tworzenia i modyfikowania dokumentów obrotowych w zdefiniowanych

okresach rozliczeniowych.

27. System musi umożliwiać wykonanie raportu z wiekowania stanów magazynowych.

7.1.1.20 Diety

Lp. Opis wymagania

1) System musi umożliwiać definiowanie diet żywnościowych.

2) System musi umożliwiać zdefiniowanie dla każdej z diet informacji o wartościach odżywczych.

Strona 84 z 204

3) System musi umożliwiać definiowanie informacji o składnikach odżywczych dla każdego z produktów.

4) System musi umożliwiać określenie kilkunastu różnych diet w jednym jadłospisie.

5) System musi umożliwiać konfigurację minimalnej i maksymalnej wartości odżywczej w danej diecie.

6) System musi umożliwiać pogląd listy produktów potrzebnych do przygotowania danej diety.

7) System musi umożliwiać tworzenie oraz modyfikacji definicji posiłków.

8) System musi umożliwiać tworzenie katalogów i zarządzania danymi:

- produktów,

- diet,

- posiłków,

- potraw,

- wartości odżywczych.

9) System musi umożliwiać zdefiniowanie dowolnej ilości posiłków dla każdej diety np.:

- śniadanie,

- drugie śniadanie,

- obiad,

- podwieczorek,

- kolacja,

- posiłek nocny.

10) System musi umożliwiać drukowanie jadłospisu dla każdej diety oddzielnie.

11) System musi umożliwiać drukowanie surowców (sumarycznie) potrzebnych do realizacji jadłospisu.

12) System musi umożliwiać zestawienie niezbędnych surowców dla wskazanej diety w wybranym jadłospisie.

13) System musi umożliwiać drukowanie wartości składników odżywczych dla diet w jadłospisie.

14) System musi umożliwiać modyfikowanie, dodawanie i usuwanie diet przez uprawnionego użytkownika z poziomu

słownika diet.

15) System musi umożliwiać zlecenie diety w trybie non-stop (od chwili zlecenia – system codziennie ponawia zlecenie

diety dla pacjenta, ponadto możliwość zmiany zleconej diety).

16) System musi umożliwiać zlecanie dodatkowych produktów żywieniowych w ramach diety indywidualnej.

17) System musi umożliwiać automatyczne rozpoczęcie zlecenia lub zakończenia zlecenia diety w przypadku przyjęcia i

wypisu pacjenta z oddziału z uwzględnieniem godziny, przerwy w żywieniu z tytułu zabiegu, wypisu na przepustkę

lub zgonu.

18) System musi umożliwiać wydruk ilości diet z uwzględnieniem lekarza i oddziału zlecającego.

19) System musi umożliwiać eksport danych w formacie .csv w zakresie diet do zewnętrznego programu.

20) System musi umożliwiać udostępnienie diet dla potrzeb kuchni w formie raportu i zestawienia (na ekranie monitora)

stanu dziennego wg jadłospisów.

21) System musi umożliwiać przeglądania stanu zbiorczego ilości żywionych pacjentów w tym:

ilość diet

Strona 85 z 204

nazwa diety

oddział zamawiający.

7.1.1.21 Leki – Zlecenia i realizacja

Lp. Opis wymagania

1. System musi umożliwiać zlecanie leków z jednoczesnym podglądem na aktualną Kartę leków pacjenta w jednym

oknie.

2. System musi umożliwiać zlecanie leków z jednoczesnym dostępem do całej dokumentacji pacjenta w jednym oknie.

3. System musi umożliwiać potwierdzenie aktualnego zlecenia bez konieczności ponownego wystawiania dzięki

automatycznemu przedłużaniu leków w ramach danego zlecenia.

4. System musi umożliwiać zawężenie listy leków do leków dostępnych w receptariuszu jednostki, tylko dostępnych,

leków pacjenta oraz leków infuzyjnych.

5. System musi umożliwiać dynamiczne wyszukiwanie leku na liście bez konieczności użycia znaków specjalnych.

6. System musi umożliwiać wyszukiwanie leków po nazwie handlowej oraz międzynarodowej.

7. System musi umożliwiać wyświetlanie (domyślnie) dostępności leków w Szpitalu już na etapie wyszukiwania leku.

8. System musi umożliwiać wyszukiwanie zamienników leku.

9. System musi umożliwiać przeglądanie CHPL leku.

10. System musi umożliwiać automatyczne podpowiadanie drogi podania leku (po jego wcześniejszym

skonfigurowaniu na poziomie Karty leku w Aptece).

11. System musi umożliwiać tworzenie słownika Uwag dołączanych do zlecenia.

12. System musi umożliwiać zlecanie leku w trybie do decyzji oraz w trybie pilnym. Wybór podania leku w trybie

pilnym skutkuje wyświetleniem wykrzyknika na Karcie leków.

13. System musi umożliwiać wyświetlanie na Karcie leków godziny, dawki podania, leków do decyzji, ewentualnych

uwag zlecającego i realizującego oraz statusu leków. Na Karcie leków musi widnieć również informacja o lekach

pacjenta.

14. System musi umożliwiać oznaczanie na Karcie leków kolorami statusu leku co najmniej potwierdzone,

zrealizowane, wstrzymane z podaniem przyczyny oraz zaplanowane - do potwierdzenia.

15. System musi umożliwiać wstrzymywanie oraz odstawiania zleconych leków z poziomu Karty leków.

16. System musi umożliwiać wyświetlanie aktualnej informacji o alergiach pacjenta na poziomie Zlecenia oraz Karty

leków.

17. System musi umożliwiać zapisywanie całego Zlecenia jak szablonu.

18. System musi umożliwiać odfiltrowanie na Karcie leków, leków do decyzji.

19. System musi umożliwiać przywrócenia leku z leków nieaktywnych z poziomu Karty leków – wyłącznie na

poziomie Apteki i odpowiednich uprawnień.

Strona 86 z 204

20. System musi umożliwiać zmianę dawki i godziny podawania leku z poziomu Karty zleceń – przy odpowiednich

uprawnieniach.

21. System musi umożliwiać wycofania potwierdzenia potwierdzonego wcześniej leku – poprzez korektę, przy

odpowiednich uprawnieniach.

22. System musi umożliwiać zlecenie leków podawanych cyklicznie z określeniem długości cyklu, godzin podawania,

dawki z podziałem na stałą i zmienną oraz określenia przerwy w podawaniu w ramach tworzonego cyklu.

23. System musi umożliwiać zlecenie leków podawanych w wybrane dni tygodnia z określeniem godzin podawania

oraz dawki z podziałem na stałą i zmienną.

24. System musi umożliwiać zlecenie leków podawanych doraźnie z określeniem ilości podań oraz dawki z podziałem

na stałą i zmienną. Po zatwierdzeniu pierwszego podania system automatycznie wylicza kolejne dawki co X

(określane na etapie tworzenia zlecenia) godzin od pierwszego podania.

25. System musi umożliwiać zlecenie leków infuzyjnych. System po wybraniu opcji Leki infuzyjne automatycznie

zawęża listę leków do roztworów do infuzji. Wybór roztworu do infuzji skutkuje zawężeniem listy

rozcieńczalników przypisanych do danego produktu. System po zmianie przepływu automatycznie przelicza czas

podawania.

26. System musi umożliwiać zlecenie leków w pompie z automatycznym wyliczaniem jej parametrów z przeliczaniem

jednostek właściwych dla danego urządzenia.

27. System musi umożliwiać modyfikację parametrów pompy w trakcie jej podawania oraz odstawienia pompyz

przeliczaniem jednostek właściwych dla danego urządzenia.

28. System musi umożliwiać dołączanie załączników do Zlecenia.

29. System musi umożliwiać przywracania ostatnio anulowanej zawartości w sytuacji przypadkowego anulowania

wystawianego Zlecenia.

30. System musi umożliwiać wydruk zlecenia lekarskiego.

31. System musi umożliwiać zawężenie listy pacjentów na oddziale do pacjentów posiadających leki do decyzji.

32. System musi umożliwiać szybkie wprowadzanie godzin podań przez dedykowane przyciski 2x, 3x, 4x na dobę wraz

z możliwością indywidualnej konfiguracji godzin dla danego oddziału

33. System dla wyróżnionych grup leków „Antybiotyki”, „P. zakrzepowe” oraz „P. cukrzycowe” musi umożliwiać

konfigurację wyników badań laboratoryjnych oraz parametrów życiowych, które będą prezentowane przy datach

podania leku

34. System musi umożliwiać sortowanie kolejności leków wg kodów ATC z możliwością indywidualnego ustalenia

porządku kodów ATC dla danego oddziału

35. System musi umożliwiać podgląd aktualnych zleceń dla oddziału w jednym oknie z możliwością zawężenia listy

przynajmniej według statusu zadania, sali, wybranego pacjenta, oraz drogi podania.

36. System musi umożliwiać oznaczanie w oknie realizacji kolorami statusu dawki leku co najmniej potwierdzone,

zrealizowane, wstrzymane z podaniem przyczyny oraz zaplanowane - do potwierdzenia.

37. System musi umożliwiać oznaczanie w oknie realizacji wykrzyknikiem (lub w inny czytelny sposób) leków

zleconych do podania w trybie pilnym.

Strona 87 z 204

38. System musi umożliwiać oznaczenie podania jako zrealizowane. System automatycznie podpowiada datę i godzinę

podania z możliwością jej zmiany. Użytkownik ma możliwość wpisania uwag do realizacji zlecenia

z możliwością tworzenia szablonów, odnotowania „niepodania” oraz ilości podanej i pobranej leku. System

automatycznie podpowiada jaką partię zużyto, partię z najkrótszą datą ważności z możliwością zmiany wyboru.

Użytkownik ma możliwość wyboru zużytej partii łącznie z zamiennikami. Odnotowana ilość leku pobranego

automatycznie jest zdejmowana ze stanu Apteczki oddziałowej.

39. System musi umożliwiać korektę transakcji zużycia (wycofanie) oraz wycofania realizacji zlecenia w sposób

audytowalny. Odnotowana i wycofana ilość leku pobranego automatycznie jest przywracana na stan Apteczki

oddziałowej. Korekty transakcji powinny być autoryzowane przez uprawnione osoby.

40. System musi umożliwiać prezentowanie informacji na karcie leków o modyfikacji ilości podanego leku (po

autoryzacji) przez personel realizujący.

41. System musi umożliwiać wydruk Listy zleconych leków do podania.

42. System musi umożliwiać automatyczne przyjmowanie, rozpisanie i realizację leków na podstawie aktualnego stanu

magazynowego apteczki oddziałowej.

43. System musi umożliwiać wydruk zleceń na środki farmaceutyczne zarówno wg pacjentów, jak i wg zleconych

leków.

44. System musi umożliwiać rozdział zleceń dla pielęgniarki lekowej (tabletki, kapsułki, etc.) i zabiegowej (iniekcje).

45. System musi umożliwiać współpracę z czytnikami kodów kreskowych i kolektorami danych przy ewidencji podania

leków pacjentowi.

46. System musi umożliwiać prowadzenie księgi realizacji zleceń lekarskich.

47. System musi umożliwiać synchronizację pomiędzy kartą zleceń lekarskich, a księgą zabiegów pielęgniarskich.

48. System musi umożliwiać prowadzenie książki leków silnie działających i narkotycznych.

49. System musi umożliwiać sprawdzenie interakcji występujących pomiędzy składnikami ordynowanych pacjentowi

leków. Wyświetlanie interakcji lub brak wyświetlania musi być konfigurowane przez każdego użytkownika

indywidualnie.

7.1.1.22 Żywienie pozajelitowe

Lp. Opis wymagania

1. System umożliwia zlecanie żywienia parenteralnego przez lekarzy w oparciu o następujące algorytmy

dla dorosłych/wg zapotrzebowania na energię, białko i płyny, możliwość uwzględnienia stanu zdrowia

pacjenta ,

dla dzieci i noworodków /wg podaży w g/kg masy ciała, możliwość uwzględnienia ilości płynów i

przyjmowanego pokarmu

wg płynów bazowych /ilość płynów bazowych w ml, procentowa ilość aminokwasów i ilość

dodatkowej wody.

Dodatkowe preparaty dodawane indywidualnie.

2. System posiada wbudowany kalkulator żywieniowy, który wylicza wszystkie istotne, z punktu widzenia stabilności,

pacjenta parametry

Strona 88 z 204

3. System umożliwia wystawianie zleceń przez lekarzy dla noworodków z uwzględnieniem czy noworodek jest

wcześniakiem z wagą poniżej 1,5kg oraz uwzględnieniem ilości przyjmowanego przez noworodka pokarmu matki

lub sztucznego

4. System podpowiada lekarzowi składy recept w zależności od stanu zdrowia pacjenta

5. System posiada możliwość modyfikacji recepty przez farmaceutę

6. System umożliwia dostęp do historii podań ze składem recept

7. System umożliwia wystawianie zleceń przez lekarzy z zastosowaniem worków RTU(dodawanie preparatów do

RTU zgodnie z charakterystyką produktu) dwu i trzykomorowych

8. System umożliwia tworzenie mieszaniny od samego początku z wykorzystaniem „worków” RTU, z użyciem

kopiowania recept bądź też za pośrednictwem stworzonych wcześniej szablonów

9. System uwzględnia limity składników narzucone przez producentów „worków” RTU zgodnie z wytycznymi

producenta.

10. System umożliwia wystawianie zleceń przez lekarzy bez stosowania algorytmówna podstawie ilości preparatów

11. System umożliwia ocenę stabilności mieszaniny w oparciu o wyliczone parametry recepty /mieszaniny podczas jej

wypisywania

12. System posiada ostrzeżenie w przypadkach przekroczeńwartości parametrów zlecanych mieszanek

13. System pozwala na zasięgnięcie informacji o witaminach i pierwiastkach śladowych podczas zlecania mieszaniny

14. System pozwala na określenie /ustalenie ilości recept ,dni dla żywienia domowego

15. System umożliwia planowanie podaży mieszaniny na recepcie na jeden dzień lub na określony czas (w przypadku

żywienia domowego)

16. System umożliwia kopiowanie recept żywieniowych wystawianych dla pacjentów

17. System pozwala na obsługę wcześniej przygotowanych mieszanek żywieniowych

18. System określa sposób podania żywienia (dojście centralne lub drogą obwodową)

19. System umożliwia elektroniczne przesłanie recepty do apteki szpitalnej /pracowni żywieniowej celem wykonania

mieszaniny

20. System umożliwia sprawdzenie i zatwierdzenie przez pracownika apteki recept wystawionych przez lekarzy- z

uwzględnieniem parametrów stabilności mieszaniny żywieniowej

21. System umożliwia wydruk zlecenia żywienia pozajelitowego

22. System umożliwia przygotowanie listy potrzeb preparatów i sprzętu w sztukach wraz z numerami serii i datą

ważności

23. System umożliwia wykonanie recept dla żywienia na weekend oraz żywienia domowego w systemie tygodniowym

24. System umożliwia dopisanie wody do worka żywieniowego potrzebnej do rozpuszczenia Soluvitu,Cernevitu

25. System umożliwia drukowanie etykiet na worki z preparatami żywieniowymi na podstawie wystawionych

receptwzór etykiety zgodny ze standardami Towarzystwa Żywienia Do i Pozajelitowego.

Strona 89 z 204

26. System umożliwia drukowanie na etykietach preparatów ,które należy dodać do worka przed podaniem pacjentowi

27. System umożliwia korzystanie z zestawień zleceń wypisywanych przez lekarzy (możliwość drukowania , imię i

Nazwisko lekarza zlecającego i pacjenta, wiek,masa dziecka. Skład mieszaniny żywieniowej, godzina

przygotowania mieszaniny, termin przydatności mieszaniny do podania, szybkość wlewu mieszaniny, podpis osoby

wykonującej)

28. System pozwala rozliczyć preparaty i sprzęt zużyty do żywienia pozajelitowego w programie aptecznym oraz na

oddziały szpitalne

29. System kontroluje numery serii i daty ważności produktów i sprzętu

30. System rozlicza koszty żywienia pozajelitowego

31. System automatycznie rozlicza mieszaniny żywieniowe na pacjenta

32. Możliwość współpracy z maszynami żywieniowymi dostępnymi na rynku

7.1.1.23 Zlecenia laboratorium

Lp. Opis wymagania

1. System musi umożliwiać elektroniczne wystawienie skierowania.

2. System musi umożliwiać automatyczne wysyłanie skierowań na badania do Laboratorium po wybraniu

odpowiedniego statusu przez użytkownika.

3. System musi umożliwiać ewidencjonowanie skierowań do laboratorium zewnętrznego.

4. System musi umożliwiać zlecanie różnych badań na podstawie wcześniej ustalonych wzorców.

5. System musi umożliwiać podgląd badań przyjętych przez laboratorium do wykonania.

6. System musi umożliwiać podgląd badań wykonanych w laboratorium.

7. System musi umożliwiać podgląd stanu realizacji zlecenia.

8. System musi umożliwiać skierowanie na badania w trybie zwykłym oraz w trybie cito.

9. System musi umożliwiać wydruku skierowania.

10. System musi umożliwiać wydruk wszystkich niezrealizowanych zleceń.

11. System musi umożliwiać zlecanie wykonania próby zgodności w pracowni serologii.

12. System musi umożliwiać wprowadzenie wyników laboratoryjnych pacjenta wykonanych poza szpitalem.

13. System musi umożliwiać pogląd wyników badań.

14. System musi umożliwiać wydruk wyników badań.

15. System musi umożliwiać identyfikację materiałów za pomocą kodów kreskowych.

Strona 90 z 204

16. System musi umożliwiać wydruk etykiet na materiały.

17. System musi umożliwiać zaewidencjonować informacje na temat osoby, która pobierała materiał do badań.

18. System musi umożliwiać wprowadzenie informacji na temat stanu zdrowia chorego.

19. System musi umożliwiać przekazania informacji do laboratorium o fakcie, że pacjent jest osobą leżącą.

20. System musi umożliwiać na ewidencjonowanie informacji o cenach badań.

7.1.1.24 Punkt pobrań

Lp. Opis wymagania

1. System musi umożliwiać integrację z wieloma systemami typu LIS.

2.

System musi zapewniać możliwość wysłania elektronicznego zlecenia do wybranej jednostki realizującej

(laboratorium).

3.

System musi zapewniać możliwość ustawienia domyślnej jednostki realizującej zlecenie dla każdej komórki

organizacyjnej (jednostki zlecającej).

4.

System musi zapewniać możliwość ewidencjonowanie informacji na temat daty, godziny oraz osoby, która

pobierała materiał do badań.

5.

System musi zapewniać możliwość wydruku zlecenia w formacie A4 lub A5 lub w formacie recepty zawierającego:

datę i godzinę pobrania materiału

kod próbki

kod zlecenia

podpis osoby pobierającej próbkę.

6.

System musi zapewniać możliwość wysłania żądania anulowania całości lub części zlecenia do momentu

otrzymania potwierdzenia od laboratorium informacji o przyjęciu tam materiału.

7. System musi zapewniać możliwość modyfikacji niezrealizowanego zlecenia.

8. System musi zapewniać możliwość podglądu stanu realizacji zlecenia (status zlecenia).

9. System musi zapewniać możliwość identyfikacji materiałów za pomocą kodów kreskowych.

10.

System musi zapewniać możliwość konfiguracji Punktu Pobrań jako osobnej jednostki dotyczącej pobierania od

pacjentów materiału oraz powiązania go za pomocą kodów ze zleceniem.

11.

System musi zapewniać możliwość konfiguracji Punktu Pobrań w ramach jednostki zlecającej dotyczącej pobierania

od pacjentów materiału oraz powiązania go za pomocą kodów ze zleceniem z danej jednostki.

12.

System musi zapewniać możliwość konfiguracji zleceń laboratoryjnych z pominięciem Punktu Pobrań w ramach

danej jednostki zlecającej - zlecenia trafiają bezpośrednio do systemu LIS.

Strona 91 z 204

7.1.1.25 Wyniki pacjenta

Lp. Opis wymagania

1. System musi udostępniać wyniki zrealizowanych zleceń (np. wynik badania) zlecającemu i uprawnionym

użytkownikom.

2. System musi zapewniać uprawnionym użytkownikom możliwość podglądu wyników badań pacjenta: z

konkretnych zleceń, z konkretnej pracowni, wszystkich wyników pacjenta.

3. System musi umożliwiać dla wyróżnionych grup leków „Antybiotyki”, „P. zakrzepowe” oraz „P. cukrzycowe”

konfigurację wyników badań laboratoryjnych oraz parametrów życiowych, które będą prezentowane przy datach

podania leku.

4. System musi zapewniać integrację z systemami typu RIS/PACS, LIS w zakresie automatycznego odbioru wyniku /

opisu zleconego badania.

5. System musi umożliwiać wydruk wyników laboratoryjnych pacjenta z podaniem zakresu dat.

6. System musi umożliwiać podgląd wyników badań pacjenta z poziomu Sali zabiegowej Pracowni, Poradni i innych

ustalonych przez użytkownika.

7. System musi umożliwiać podgląd wszystkich wyników badań pacjenta w jednym miejscu z możliwością

filtrowania po rodzaju badania co najmniej laboratoryjne, obrazowe.

8. System musi umożliwiać podgląd wszystkich wyników badań pacjenta w jednym miejscu z możliwością

filtrowania po dacie (bądź zakresie dat) badań.

9. System musi umożliwiać podgląd wyników badań w formie tabelarycznej z kolorystycznym rozróżnieniem

wartości poza normą.

10. System musi umożliwiać podgląd wyników badań w formie wykresów z oznaczeniem wartości poza normą z

możliwością wyboru badań jakie na wykresie mają się znaleźć.

11. System musi posiadać interaktywne wykresy wyników laboratoryjnych prezentując zmiany koloru ekranu dla

wyników badań poza normą.

12. System musi posiadać funkcjonalność informowania lekarza o wynikach do rozliczenia w ramach bieżącej wizyty.

13. System musi umożliwiać dołączenie do dokumentacji medycznej zewnętrznych wyników badań.

14. System musi umożliwiać odbieranie i przeglądanie wyników badań Mikrobiologii i histopatologii.

7.1.1.26 Recepty

Lp. Opis wymagania

1. System musi umożliwiać wystawianie e-recept, recept i wydruku recept, zgodnie z obowiązującymi przepisami

prawa.

2. System musi umożliwiać definiowanie puli numerów nanoszonych na recepty indywidualnie dla każdego lekarza

poprzez import puli z pliku xml lub poprzez ręczne definiowanie puli.

Strona 92 z 204

3. System musi umożliwiać zbiorcze przeglądanie przydzielonych lekarzom pól recept i wyróżnia pozycje, dla których

dostępna konfigurowalna minimalna ilość numerów recept została przekroczona.

4. System musi umożliwiać wydruk pełnej treści recepty (w tym dane pacjenta, leki, ich ilość, dawkowanie, informacje

o odpłatności itp.) z możliwością określenia puli numerów recept dla danego lekarza.

5. System musi umożliwiać wydruk pustych recept, na których personel medyczny będzie mógł ręcznie wpisać nazwy

leków, dawkowanie, odpłatność.

6. System musi umożliwiać prezentowanie informacji o ilości numerów recept pozostałych do wykorzystania.

7. System musi umożliwiać generowanie ostrzeżenia dla użytkownika w przypadku próby edycji lub ponownego

wydruku już wydrukowanej recepty.

8. System musi umożliwiać posiadanie niezależnych pul recept uwzględniając typ recepty RPW.

9. System musi umożliwiać tworzenie recept wraz z wpisem o zleconych lekach do dokumentacji medycznej pacjenta,

zapewniającym generowanie raportów zawierających informacje o ilości, asortymencie, odpłatnościach itp.

Przepisywanych leków przez poszczególnych lekarzy i zbiorczo oraz gromadzi informacje o zażywanych przez

pacjenta lekach (okres przyjmowania, dawkowanie itp.).

10. System musi umożliwiać wprowadzanie adnotacji do wystawianych recept.

11. System musi umożliwiać automatyczne dodawanie opisu słownego leków psychotropowych i odurzających na

receptach realizowanych z puli recept RPW.

12. System musi umożliwiać tworzenie szablonów recept oraz kopiowanie: wszystkich leków z wybranej recepty,

wybranego leku z recept wystawionych wskazanego dnia w tym z poprzedniej wizyty.

13. System musi umożliwiać wybór leków, które mają być zamieszczone na recepcie w oparciu o zaimportowaną bazę

leków.

14. System musi umożliwiać wydruk numeru dokumentu tożsamości obcokrajowca na recepcie.

15. System musi umożliwiać wyliczanie wieku pacjenta na podstawie jego daty urodzenia.

16. System musi umożliwiać ewidencjonowanie wystawionych recept zgodnie z obowiązującymi przepisami.

17. System musi umożliwiać zaimportowanie jednego z dostępnych słowników leków (np. Pharmindex, BLOZ,

BAZYL, LEKSEEK) wykorzystywanego na potrzeby wystawiania recept oraz musi zapewniać jego aktualizację do

najnowszej wersji oraz musi współpracować z wieloma bazami produktów leczniczych jednocześnie. Wskazana

baza leków musi zostać zaimportowana na etapie wdrażania systemu na koszt Dostawcy.

18. System musi umożliwiać dodawanie do słownika leków recepturowych z określeniem ich składników oraz zapewnia

wydruk składników leku recepturowego.

19. System musi umożliwiać udostępnianie podręcznej listy leków ordynowanych przez danego lekarza, z możliwością

jej edycji.

20. System musi umożliwiać przeglądanie CHPL leku.

21. System musi umożliwiać prezentację listy leków udostępniając minimum: nazwę, substancję czynną, postać, dawkę,

informację o opakowaniu (dla leków recepturowych System prezentuje nazwę).

22. System musi umożliwiać automatyczne nanoszenie na receptę informacji, które mogą być naniesione

Strona 93 z 204

automatycznie, np.: informacje o świadczeniodawcy, komórce organizacyjnej, lekarzu wystawiającym.

23. System musi umożliwiać przy wypisywaniu recepty prezentowania informacji o zasadach odpłatności za

ordynowany lek, w zależności od: obowiązujących zasad wynikających z zapisów prawa, w tym rozpoznania,

uprawnień pacjenta i jego wieku (w tym zasad obowiązujących odnośnie pacjentów POZ, którzy ukończyli 75. Rok

życia).

24. System musi umożliwiać wyszukiwanie odpowiedników ordynowanych leków, m.in. wg najniższej ceny DDD dla

pacjenta lub umożliwiać wystawienie recepty wyłącznie z pozostawieniem nazwy międzynarodowej.

25. System musi umożliwiać sprawdzenie interakcji występujących pomiędzy składnikami ordynowanych pacjentowi

leków w ramach danej wizyty i wizyt wcześniejszych zaewidencjonowanych w Systemie. Wyświetlanie interakcji

lub brak wyświetlania musi być konfigurowane przez każdego użytkownika indywidualnie.

26. System musi umożliwiać generowanie raportów zawierających informacje o ilości, asortymencie, odpłatnościach

przepisywanych leków przez poszczególnych lekarzy i zbiorczo dla lekarzy i jednostek organizacyjnych.

27. System musi umożliwiać dostęp do funkcjonalności drukowania i wypełniania recept stosownie do nadanych

uprawnień

7.1.1.27 Rehabilitacja

Lp. Opis wymagania

1. System musi umożliwiać obsługę zleceń dla:

- rehabilitacji ambulatoryjnej

- rehabilitacji oddziału dziennego

- rehabilitacji pacjentów hospitalizowanych.

- System musi umożliwiać zlecanie i realizację świadczeń z zakresu fizjoterapii polegających na diagnostyce

funkcjonalnej pacjenta, kwalifikowaniu, planowaniu i prowadzeniu fizykoterapii, kinezyterapii lub masażu w

zależności od uprawnień personelu;

2. System musi umożliwiać obsługę zleceń z jednostek wewnętrznych jak i zewnętrznych.

3. System musi umożliwiać zarządzanie grafikami i terminarzami:

- personelu

- stanowisk i urządzeń rehabilitacyjnych.

4. System musi umożliwiać generowanie zestawień wykonanych zabiegów przez poszczególnych pracowników.

5. System musi umożliwiać pełną integrację działu fizjoterapii z poradnią i oddziałem, co niesie za sobą automatyczne

wysyłanie zleceń i odbieranie informacji o realizacji zlecenia. System musi umożliwiać integrację w zakresie

przesyłania danych o kosztach zabiegów na pacjenta do KKL

6. System musi umożliwiać automatyczne podpięcie procedur i produktów związanych z zabiegiem w momencie

oznaczenia jego realizacji.

7. System musi umożliwiać wyszukiwanie cyklu co najmniej po kryteriach takich jak:

- status

- płatnik

- zakres dat

- imię pacjenta

- nazwisko pacjenta

Strona 94 z 204

- PESEL pacjenta.

8. System musi umożliwiać sortowanie wyszukanych cykli po co najmniej kryteriach takich jak:

1. nazwisko pacjenta

2. data rozpoczęcia

3. data zakończenia.

9. System musi umożliwiać przeglądanie wszystkich grafików fizjoterapeutów/zasobów/gabinetów utworzonych w

ramach jednostki w jednym oknie.

10. System musi umożliwiać przeglądanie ilości zaplanowanych / wolnych wizyt dla wszystkich zasobów jednostki w

jednym miejscu.

11. System musi umożliwiać szybkie przejście do dnia dzisiejszego.

12. System musi umożliwiać zarządzanie słownikami:

- stanowisk i urządzeń rehabilitacyjnych

- gabinetów

- zabiegów.

13. System musi umożliwiać tworzenie blokad oraz komentarzy dla pojedynczych wizyt oraz dla całego dnia.

14. System musi umożliwiać określenie standardowych czasów trwania zabiegów.

15. System musi umożliwiać automatyczne planowanie na bazie dostępności osób i urządzeń.

16. System musi umożliwiać korzystanie z kalendarza planowania z wizualizacją zajętych slotów na zabiegi przez

innych pacjentów, blokady terminów.

17. System musi umożliwiać drukowanie planu zabiegów.

18. System musi umożliwiać wyszukanie pierwszego terminu wolnego jak i pozostałe terminy można wyszukać poprzez

opcję „wyszukiwanie wolnych terminów”. Wpisując dzisiejszy lub dogodny termin wizyty system wyszukuje czy są

wolne miejsca w celu jego rezerwacji dla pacjenta.

19. System musi umożliwiać automatyczne planowania cykli umożliwiająca planowanie w zależności od potrzeb

konkretnej jednostki.

20. System musi umożliwiać ręczne planowanie zabiegów.

21. System musi umożliwiać wydruk dziennej listy pacjentów.

22. System musi umożliwiać wydruk dziennej listy cykli dla cykli rozpoczynających się w danym dniu.

23. System musi umożliwiać przerwanie planowania na wybranym przez siebie etapie i powrócić do niego w dogodnym

momencie.

24. System musi umożliwiać automatyzację realizacji wizyty poprzez:

realizację pozycji zlecenia za pomocą kodu kreskowego

automatyczne dopisywanie do rozliczeń procedur (w tym procedur zależnych od parametrów zlecenia)

oraz produktów podczas realizacji zabiegów.

25. System musi umożliwiać zawężanie listy zabiegów do wykonania po co najmniej:

zasobie

zabiegu

Strona 95 z 204

tylko zleceniach wewnętrznych

odwołanych

zakresie dat

zakresie godzin.

26. System musi umożliwiać odwołanie zabiegu z podaniem przyczyny odwołania.

27. System musi umożliwiać przeglądanie stanu realizacji cyklu.

28. System musi umożliwiać anulowanie wykonania.

29. System musi umożliwiać sprawdzenie statusu eWuś.

30. System musi umożliwiać automatyzację realizacji zabiegów poprzez co najmniej realizację pozycji zlecenia za

pomocą kodu kreskowego bez potrzeby wybierania ręcznego pacjenta, zlecenia.

31. System musi umożliwiać prowadzenie karty badania i realizacji zabiegów fizjoterapeutycznych wykonywanych u

pacjenta.

32. System musi umożliwiać generowanie elektronicznego zlecenia zabiegów rehabilitacyjnych z gabinetu poradni

specjalistycznych oraz przesyłanie informacji zwrotnych z fizjoterapii do osoby wystawiającej zlecenie co do

przeprowadzonego badania i kwalifikacji pacjenta do leczenia rehabilitacyjnego.

33. System musi umożliwiać zlecenie wyrobów medycznych, zgodnie z przepisami wydanymi na podstawie art. 38 ust.

4 ustawy z dnia 12 maja 2011 r. o refundacji leków, środków spożywczych specjalnego przeznaczenia

żywieniowego oraz wyrobów medycznych .

34. System musi umożliwiać generowanie opinii i orzeczeń odnośnie do stanu funkcjonalnego osób poddawanych

fizjoterapii oraz przebiegu procesu fizjoterapii;

7.1.1.28 Rozliczenia z NFZ

Lp. Opis wymagania / punktacja

1. System musi zapewniać pełną integrację i wymianę danych z pozostałymi modułami HIS. Automatyczne

księgowanie się całej sprzedaży po stronie modułu Księgi Głównej z uwzględnieniem właściwych schematów

księgowych oraz cech transakcji (wymiarów, np. MPK/OPK).

2. System musi umożliwiać nanoszenia podstawowych danych kontrahentów:

1. nazwa i adres

2. NIP

3. REGON.

3. System musi umożliwiać ewidencjonowanie umów zawartych z oddziałami NFZ.

4. System musi umożliwiać generowanie dokumentów rozliczeniowych.

5. System musi umożliwiać weryfikację kompletu danych niezbędnego do rozliczenia wizyt/pobytów pacjentów.

6. System musi umożliwiać raportowanie braków w danych niezbędnych do rozliczenia świadczeń.

7. System musi umożliwiać automatyczne przyporządkowywanie wizyt i pobytów pacjentów w szpitalu lub innej

jednostce służby zdrowia do pozycji umów z płatnikami oraz przypisywanie im kwot refundacji zgodnie z

wprowadzoną umową.

Strona 96 z 204

8. System musi umożliwiać wystawienie faktur dla płatnika na podstawie dokumentów rozliczeniowych.

9. System musi umożliwiać generowanie szeregu zestawień sprawozdawczych do NFZ, Centrum Zdrowia

Publicznego, zgodnie z obowiązującymi przepisami oraz wewnętrznych raportów weryfikujących dane bez

konieczności stosowania zewnętrznych programów, między innymi:

zestawienie świadczeń za wybrany okres z możliwością weryfikacji definiowalnego kompletu

danych rozliczeniowych

zestawienie świadczeń rozliczonych w danym okresie, na podstawie wybranych umów

zbiorcze zestawienia ilościowo - wartościowe za dany okres rozliczeniowy, na podstawie

wybranych umów

zestawienie wykonanych usług ponadplanowych

zestawienie pacjentów nie wykazanych na dokumentach rozliczeniowych, wraz z powodem ich nie

uwzględniania w rozliczeniach

zestawienia pobytów pacjentów powtarzających się częściej niż zadany odstęp czasu

generowanie sprawozdania do NFZ dot. liczby oczekujących i średniego czasu oczekiwania na

świadczenia, oraz pierwszego wolnego terminu

generowanie pełnej sprawozdawczości statystyczno-rozliczeniowej do NFZ.

10. System musi umożliwiać korygowanie danych rozliczeniowych poprzez podniesienie wersji jednego

świadczenia lub zestawu świadczeń oraz wielu w zakresie danych statystycznych i rozliczeniowych.

11. System musi umożliwiać z poziomu Raport JGP łatwy i szybki wgląd w wyniki jednostki.

12. System musi umożliwiać zintegrowanie Raportu JGP z Optymalizatorem JGP.

13. System musi umożliwiać wyróżnienie miejsc, w których można dokonać korekty tak, aby uzyskać lepsze

wyniki finansowe i medyczne pracy Szpitala.

14. System musi umożliwiać zaimplementowanie algorytmu grupera (zgodnie z zapisami Zarządzenia Nr

33/2011/DSOZ Prezesa Narodowego Funduszu Zdrowia z dnia 6 lipca 2011 r. w sprawie określenia warunków

zawierania i realizacji umów w rodzaju: leczenie szpitalne), który na etapie kodowania rozpoznań i procedur

dotyczących danej hospitalizacji umożliwi:

- określenie grupy JGP z najwyższą taryfą na podstawie wprowadzonych danych wraz z określeniem listy

grup alternatywnych JGP;

- określenie listy grup JGP odrzuconych wraz z podpowiedzią warunków kierunkowych koniecznych do

spełnienia.

Wersja słownika procedur ICD9 oraz leków w programach lekowych musi być uaktualniana na bieżąco.

15. System musi umożliwiać określenie grupy JGP bez konieczności komunikacji z NFZ natychmiast po

wprowadzeniu niezbędnych danych wraz z prezentacją osobodni pacjenta w odniesieniu do liczby dni

finansowanych grupą JGP oraz informacji o dostępnym limicie i o bieżącej realizacji umowy.

16. System musi umożliwiać wprowadzanie rozliczeń JGP w oparciu o:

przeglądarkę grup JGP (słownik zawiera wyróżnione grupy JGP, które mogą być rozliczone w

poszczególnych produktach zakontraktowanych przez szpital zgodnie z poszczególnymi zakresami

świadczeń (zgodnie z zgodnie z zarządzeniami Prezesa NFZ), albo wbudowanego grupera.

odrębne słowniki katalogów świadczeń wskazane prze NFZ (słownik powinien mieć wyróżnione

produkty, które mogą być rozliczone w poszczególnych oddziałach zakontraktowanych przez

szpital zgodnie z poszczególnymi zakresami świadczeń (zgodnie z zarządzeniami Prezesa NFZ).

17. System musi zapewniać zgodność z najnowszymi wytycznymi NFZ w sprawie grupowania (przeprowadzana na

bieżąco implementacja zmian ogłaszanych przez NFZ).

Strona 97 z 204

18. System musi umożliwiać dostęp do funkcjonalności optymalizatora i grupera w zakresie:

wyznaczania grup JGP,

wyznaczania ambulatoryjnych grup świadczeń specjalistycznych,

wyznaczania grup w zakresach stacjonarnej rehabilitacji neurologicznej i kardiologicznej,

obliczania ich wartości punktowych,

przeprowadzania symulacji grupowania/optymalizacji opłacalności,

licencji nieograniczonej do liczby stanowisk,

sugerowania zmian w kodowaniu.

19. System musi umożliwiać wyznaczanie JGP zgodnie z charakterystyką i algorytmem określonym przez NFZ na

dany okres rozliczeniowy.

20. System musi umożliwiać obsługę wyznaczania JGP dla danych z zakończonych okresów rozliczeniowych

zgodnie z obowiązującą wtedy charakterystyką i algorytmem.

21. System musi umożliwiać automatyczne pobieranie z Ruchu Chorych wszystkich dane niezbędnych do

wyznaczenia JGP.

22. System musi umożliwiać wyznaczanie wszystkich możliwych grup do jakich może zostać zakwalifikowana

hospitalizacja zgodnie z zawartą umową z NFZ.

23. System musi umożliwiać wyznaczanie wszystkich możliwych grup do jakich może zostać zakwalifikowana

porada zgodnie z zawartą umową z NFZ.

24. System musi umożliwiać wyliczanie dla każdej wyznaczonej grupy wartości punktowej niezbędnej do

sprawozdawczości (taryfa podstawowa, dodatkowa, całkowita).

25. System musi umożliwiać automatyczne podpowiadanie grupy do rozliczenia kierując się kryterium

optymalizacji przychodu za wykonanie określonego rodzaju świadczenia i spełnienia warunku, że znajduje się

w umowie.

26. System musi umożliwiać zawężenie przeglądania JGP do zakontraktowanych z danym płatnikiem, w danej

jednostce organizacyjnej.

27. System musi umożliwiać automatyczne wyznaczanie także innych potencjalnych grup w przypadku

alternatywnej kwalifikacji świadczenia z jawnym oznaczeniem grupy najbardziej intratnej.

28. System musi umożliwiać wskazywanie dokładnie przyczyny braku możliwości zakwalifikowania świadczenia

do bardziej intratnej grupy.

29. System musi umożliwiać automatyczne porządkowanie (sortowanie) wyznaczone i potencjalne grupy wg

kryterium łącznej wartości punktów.

30. System musi umożliwiać przypisanie na podstawie wyznaczonej JGP produktu jednostkowego do rozliczenia

w NFZ.

31. System musi umożliwiać obsługę zleceń zamówienia na wyroby medyczne.

32. System musi umożliwiać importowanie i eksportowanie karty udarowej do aplikacji NFZ.

33. System musi umożliwiać rozliczanie programów lekowych oraz leczniczych.

Strona 98 z 204

7.1.1.29 Rozliczenia komercyjne

Lp. Opis wymagania

1. W zakresie obsługi pacjentów obsługiwanych poza umową z NFZ systemu powinien umożliwiać :

wprowadzanie listy usług,

wprowadzenie danych usługi:

o płatnika,

o wymagalność skierowania, usługa powinna mieć zdefiniowaną wymagalność skierowania lub

też nie.

wprowadzanie cenników:

o okres obowiązywania,

o godziny dostępności,

o możliwość definicji cenników standardowych i specjalnych,

o miejsca realizacji,

wprowadzanie rabatów:

o rabaty ogólne do wykorzystania bez ograniczeń,

o rabaty prywatne – przyporządkowane do osoby,

2. W zakresie obsługi pacjentów obsługiwanych poza umową z NFZ systemu powinien umożliwiać :

obsługę skorowidza pacjentów,

konstruowanie produktów:

o wprowadzanie danych podstawowych produktu,

o wprowadzanie zakresów usług medycznych w ramach produktu,

o wprowadzanie usług medycznych w ramach zakresu (poradnia, szpitalnictwo, diagnostyka),

3. W zakresie obsługi pacjentów obsługiwanych poza umową z NFZ systemu powinien umożliwiać :

wprowadzanie trybów i terminów płatności dla zakresów:

o abonament, (niezależnie od wykonanych usług),

o FFS (Fee For Service czyli za każde wykonanie usługi),

o współpłatność w ramach FFS,

o płatności mieszane,

o usługi nieodpłatne, (w pakiecie)

4. W zakresie obsługi pacjentów obsługiwanych poza umową z NFZ systemu powinien umożliwiać :

grupowanie zakresów usług,

ewidencję i obsługę umów:

obsługę umów na sprzedaż usług medycznych:

umowy ubezpieczeniowe,

umowy abonamentowe,

umowy z innymi ZOZ-ami, Indywidualnymi Praktykami Lekarskimi, pacjentami zagranicznymi

wprowadzanie danych podstawowych umowy,

przypisywanie produktu do umowy,

definiowanie rabatów dla umowy,

5. W zakresie obsługi pacjentów obsługiwanych poza umową z NFZ systemu powinien umożliwiać :

wprowadzanie list uprawnionych do grup zakresów:

beneficjenci,

tworzenie produktu dedykowanego dla umowy,

definiowanie wzorów faktur i załączników do faktur dla umowy,

mechanizm importu list uprawnionych pacjentów danego kontrahenta wraz z jego danymi, datą

obowiązywania uprawnień oraz statusem,

wydruk usług zawierających się w umowie, na potrzeby informacyjne

Strona 99 z 204

6. W zakresie obsługi pacjentów obsługiwanych poza umową z NFZ systemu powinien umożliwiać :

rozliczanie umów:

o generowanie harmonogramów płatności umowy w oparciu o dane zakresów umowy,

o generowanie danych do faktur i załączników do faktur płatnych abonamentowo w oparciu o

zdefiniowany wzorzec i dane umowy,

o generowanie danych do faktur i załączników do faktur płatnych za wykonanie w oparciu o

zdefiniowane wzorce i dane umowy oraz dane o wykonanych usługach.

o automatyczne księgowanie w FK wystawionych faktur.

7.1.1.30 Terminarz

Lp. Opis wymagania

1. System musi umożliwiać definiowanie grafików pracy (terminarzy) dla wskazanej osoby (personelu) w komórce,

urządzenia, stanowiska, gabinetu, zwanych dalej zasobami.

2. System musi umożliwiać generowanie grafików na podstawie wcześniej przygotowanych szablonów (np.

definiujących dany grafik dla wszystkich dni tygodnia, utworzony ręcznie przez operatora lub określony na

podstawie wybranego tygodnia, dla którego grafiki lub szablony określono wcześniej, wraz z definicją zastrzeżeń

(rodzaju/treści blokady) godzin przyjęć w dniu) w taki sposób, aby w wyniku pojedynczej operacji możliwe było

zdefiniowanie grafiku opcjonalnie na okres: roczny, półroczny, kwartalny, miesięczny, tygodniowy lub na dany

dzień dla wybranego (opcjonalnie): personelu, gabinetu, komórki organizacyjnej, obiektu, całej przychodni.

3. System musi umożliwiać generowanie szablonów tygodniowych, umożliwiających specyfikowanie grafiku pracy w

wybrane dni tygodnia (w tym pracę np. w n-ty piątek miesiąca), a następnie umożliwia tworzenie na ich podstawie

grafików zgodnie z wymaganiami określonymi wyżej.

4. System musi umożliwiać generowanie zastrzeżeń (rodzaju/treści blokady) w ramach danego grafiku odnośnie dni i

godzin przyjęć z możliwością dowolnego określenia przyczyny zastrzeżenia (np. urlop, zwolnienie lekarskie, termin

do dyspozycji lekarza, wizyta komercyjna, cito itp.).

5. System musi umożliwiać definiowanie lub korygowanie grafiku z pominięciem szablonu.

6. System musi podczas generowania grafików automatycznie uwzględniać dni świąteczne i ustawowo wolne od

pracy (funkcja: nie generuj grafiku na takie dni). Zamawiający dopuszcza konieczność wcześniejszego

zdefiniowania

w programie przez administratora dni świątecznych "ruchomych".

7. System musi umożliwiać prezentację stanu dostępności miejsc w grafiku, prezentując: czy w danym dniu są wolne

miejsca, ile jest tych miejsc (z wykorzystaniem zobrazowania symbolicznego, liczbowego, kolorystyki).

8. System musi umożliwiać prezentację (w postaci skrótów literowych, symboli i wyróżników kolorami) stan

wprowadzenia informacji odnośnie wizyt i pacjentów, pokazując zarezerwowane wizyty w grafiku z informacją np.

o tym, czy dana wizyta odbyła się, czy pacjent posiada skierowanie, status Ewuś, wpis do kolejki oczekujących.

9. System musi umożliwiać planowanie i rezerwację terminów wizyt na dowolny okres w przód, w tym telefonicznie

zgodnie z wprowadzonym grafikiem. W momencie rozpoczęcia nowej rezerwacji prezentować informację o

najbliższym wolnym terminie do danej poradni, pracowni i zasobu oraz umożliwia domyślny wybór tego terminu.

10. System musi umożliwiać zmianę terminu rezerwacji wizyty z ewidencją przyczyny zmiany na podstawie słownika

bez konieczności ponownego rejestrowania pacjenta lub wizyty.

11. System musi umożliwiać odwołanie terminu rezerwacji wizyty z ewidencją przyczyny odwołania na podstawie

słownika z możliwością prezentacji terminów odwołanych.

Strona 100 z 204

12. System musi umożliwiać planowanie wizyt (stosownie do posiadanych uprawnień w tym zakresie przez

użytkownika) w terminach nie wynikających z prowadzonego grafiku lub jako wizyt dodatkowych na już zajęte

terminy (niezbędne dla rejestracji przypadków pilnych, zleconych przez lekarza itp.).

13. System musi umożliwiać korzystanie z terminarza z poziomu Poradni oraz Pracowni.

14. System musi umożliwiać prowadzenie terminarza w podziale na komórkę organizacyjną oraz zasoby (np. lekarz,

urządzenie, gabinet). W terminarzu powinna być wyświetlana jest aktualna ilość pacjentów zaplanowanych, ilość

wolnych terminów oraz całkowita ilość terminów na dany zasób

15. System musi umożliwiać wyświetlanie informacji o ilości wszystkich zaplanowanych wizyt do danego

lekarza/zasobu we wszystkich poradniach, oddziałach.

16. System musi umożliwiać wyszukiwanie wolnego terminu o kryterium rodzaju/treści blokady (możliwość

ograniczenia wyświetlenia terminów tylko dla tych kryteriów).

17. System musi umożliwiać definiowanie rodzaju/treści blokady dodatkowo w momencie tworzenia grafiku (na

zadany slot czasowy).

18. System musi umożliwiać przeniesienie między poradniami (w szczególności jeśli są takiego samego typu),

możliwość grupowego przenoszenia. Możliwość przenoszenia zaplanowanych wizyt z oddziału dziennego do

poradni.

19. System musi umożliwiać pracownikom rejestracji z poziomu pacjenta przeglądanie wizyt, zaplanowanych wizyt ich

statusów, anulowanie, przeniesienie wizyt pacjenta, druku oświadczeń itp. pacjenta.

20. System musi umożliwiać , z poziomu terminarza, wydruku list zaplanowanych pacjentów (np. wydruk na lekarza z

wszystkich poradni.

21. System musi umożliwiać rejestrowanie na lekarza (możliwość wyświetlenia jego wolnych terminów z wszystkich

poradni w jednym oknie).

22. System musi umożliwiać powiadamianie pacjentów i przypomnienie mail-owe oraz SMS-owe o zaplanowanej,

odwołanej wizycie (w zadanej poradni, dla zadanego lekarza).

23. System musi umożliwiać rejestrowanie na wiele wizyt przy jednokrotnym uzupełnieniu danych rejestracyjnych

pacjenta (jednostka rozliczeniowa, tryb przyjęcia, skierowanie).

24. System musi umożliwiać wydruk "Listy wizyt" posortowanej alfabetycznie.

25. System musi umożliwiać nadpisywanie szablonu grafiku wraz z usunięciem rodzaju/treści blokady.

26. System musi umożliwiać wybranie wielu jednostek (poradni) przy wyszukiwaniu wolnego terminu.

27. System musi umożliwiać prezentację statusu wizyty (Zrealizowano, Niezrealizowana oraz Przyjęty (status pośredni

- wizyta rozpoczęta, niezakończona na liście pacjentów zaplanowanych w danym dniu do danego zasobu.

28. System musi umożliwiać z poziomu terminarza ewidencję obecności pacjenta.

29. System musi umożliwiać z poziomu terminarza bezpośrednie przejście do danych osobowych pacjenta, do realizacji

wizyty w gabinecie, bezpośrednie przejście do pobytu oraz możliwość przeniesienia wizyty do wybranej poradni.

Strona 101 z 204

7.1.1.31 Gabinet

Lp. Opis wymagania

1. System musi umożliwiać konfigurowanie jednostek za pomocą przypisywania określonych cech do komórek

organizacyjnych. W zależności od rodzaju przypisanej cechy dostępne są dostosowane to danego rodzaju

jednostki formularze i wydruki dokumentacji medycznej, tryb rozliczania świadczeń realizowanych w danej

jednostce, prezentowanie lub ukrywanie danych medycznych pacjentów w innych jednostkach.

2. System musi umożliwiać ewidencję i umożliwiać wydruk niezbędnej dokumentacji medycznej zawierającej

wszystkie wymagane prawem elementy, m. in.: wywiad wstępny (przedmiotowo, podmiotowo), przebieg

choroby, wykonane procedury, wyniki badań diagnostycznych i laboratoryjnych, zalecenia lekarskie, zlecone

konsultacje, przepisane leki i wystawione recepty, zlecenia badań, z możliwością indywidualizacji dla danej

jednostki organizacyjnej.

3. System musi umożliwiać odwołanie planowanej wizyty z poziomu gabinetu.

4. System musi umożliwiać zarejestrowanie pacjenta z poziomu gabinetu.

5. System musi umożliwiać dostęp do archiwalnych wyników badań pacjenta.

6. System musi umożliwiać generowanie raportu, podsumowującego wizyty danego lekarza z wszystkich poradni, z

informacjami o rozpoznaniach, typie wizyty, wykonanych ICD9 itp.

7. System musi umożliwiać podpowiadanie wykonanych badań, które będą rozliczane w ramach wizyty/pobytu.

8. System musi umożliwiać dokonywanie wyboru wykonanych podczas wizyty procedur w postaci zdefiniowanych

grup.

9. System musi umożliwiać filtrowanie listy pacjentów na dany dzień po statusie wizyty (Obecni, Nieprzyjęci,

Przyjęci, Wszystkie).

10. System musi umożliwiać podsumowanie ilości pacjentów w gabinecie w danym dniu w podziale na:

Zrealizowani, Niezrealizowani, Przyjęci.

11. System musi umożliwiać skonfigurowanie alertów, np. o koniecznym wybraniu rozpoznania czy procedury, tak

by można było prawidłowo wizytę rozliczyć.

12 System musi umożliwiać dostosowanie wydruków do formatu A5 (dotyczy głównie karty wizyty).

13 System musi umożliwiać ewidencjonowanie podawania kontrastu przy diagnostyce obrazowej w obszarze

poradni.

14 System musi umożliwiać generowanie karty znieczulenia przy zabiegach wymagających asysty anestezjologa.

15 System musi umożliwiać prowadzenie siatki centylowej

16 System musi umożliwiać zbiorczy wydruku wszystkich kart wizyt pacjenta z danej poradni.

17 System musi umożliwiać wydruk raportu (PDF oraz arkusz kalkulacyjny) w celu podsumowania wykonanych

wizyt przez lekarza, zawierającego informacje o wykonanych elementach leczenia.

18 System musi umożliwiać automatyczne wyliczanie wskaźnika BSA oraz BMI w karcie wizyty na podstawie

masy i wzrostu pacjenta.

19 System musi posiadać osobne uprawnienie do przeniesienia terminu planowanej wizyty z oddziału do poradni

Strona 102 z 204

oraz do zarejestrowania pacjenta w gabinecie (bez możliwości rejestracji nowych pacjentów w terminarzu

poradni).

20 System musi umożliwiać przeglądanie oraz odnotowanie informacji o stałych lekach i chorobach pacjenta

bezpośrednio z gabinetu.

21 System musi umożliwiać przeglądanie z poziomu gabinetu poprzednich oraz zaplanowanych wizyt pacjenta.

22 System musi umożliwiać dostęp do przeglądania pełnej historia choroby pacjenta w zależności od uprawnień

użytkownika.

23 System musi umożliwiać dostęp do podglądu wyników badań. W przypadku wyników badań laboratoryjnych

w formie tabelarycznej powinny zostać oznaczane wartości odstające, w formie wykresu z powinna istnieć

możliwość wyboru parametrów znajdujących się na wykresie.

24 System musi umożliwiać wystawianie zleceń, skierowań, recept.

25 System musi umożliwiać ewidencjonowanie danych wizyty (potwierdzenie obecności pacjenta, przegląd,

wprowadzanie i modyfikacja danych o wizycie), przeglądu i edycji (stosownie do posiadanych uprawnień)

danych pacjenta.

26 System musi umożliwiać użytkowanie zdefiniowanych wcześniej wzorców dokumentacji dedykowanych dla

danego typu wizyty (w zależności od specjalności wizyty i gabinetu).

27 System musi umożliwiać automatyczną, konfigurowalną (w zależności od specyfiki danego zasobu)

generowanie, wydruk i przegląd księgi gabinetu, poradni, pracowni.

28 System musi umożliwiać ewidencjonowanie realizowanych usług w gabinecie i pracowni, która na ich podstawie

umożliwia wygenerowanie i wydruk księgi wykonywanych zabiegów.

29 System musi umożliwiać generowanie wydruku informacji dla lekarza POZ o stanie zdrowia pacjenta oraz

zaleceniach.

30 System musi umożliwiać generowanie raportów, wykazów i wydruków niezbędnych dla pracy gabinetu według

potrzeb Zamawiającego.

31 System musi umożliwiać przegląd terminarza wizyt z gabinetu i pracowni.

32 System musi umożliwiać prowadzenie apteczek gabinetowych, odnotowywanie użytych, wydawanych lub

podanych pacjentom materiałów medycznych, substancji, szczepionek i leków oraz materiałów

wykorzystywanych do realizacji usług w gabinetach i pracowniach diagnostycznych.

33 System musi umożliwiać generowanie zestawień w zakresie użytych, wydawanych lub podanych pacjentom

materiałów medycznych, substancji, szczepionek i leków oraz materiałów wykorzystywanych do realizacji usług

w pracowniach diagnostycznych w rozbiciu na: pacjenta, gabinet, komórkę organizacyjną oraz w zakresie stanów

magazynowych. Raportowanie programów lekowych, integracja danych na poziomie wszystkim modułów

systemu (Apteka, Apteczka oddziałowa, Statystyka, itd.).

34 System musi umożliwiać wydruk zaświadczenia lub orzeczenia lekarskiego.

35 System musi umożliwiać przegląd wpisów w dokumentacji medycznej pacjenta w odniesieniu do wykazu

zrealizowanych wizyt i wymienionych w poprzednim punkcie elementów.

36 System musi umożliwiać zaewidencjonowanie i wydruk leków z dawkowaniem dla pacjenta (zarówno

wydawanych na receptę jak i bez).

Strona 103 z 204

37 System musi umożliwiać dostęp i możliwość wykorzystania opisów, wywiadów lub wyników badań

zaewidencjonowanych wcześniej.

38 System musi zapewniać jednoznaczną autoryzację opisu wizyty przez uprawnioną osobę (np. lekarza),

uniemożliwiając dokonywanie czynności edycyjnych nieuprawnionym użytkownikom.

39 System musi umożliwiać rezerwację kolejnej wizyty bezpośrednio z gabinetu dla uprawnionych do tej czynności

użytkowników.

40 System musi umożliwiać generowanie elektronicznego zlecenia zabiegów rehabilitacyjnych z gabinetu poradni

specjalistycznych oraz przesyłanie informacji zwrotnych z fizykoterapii do lekarza wystawiającego zlecenie co

do przeprowadzonego badania i kwalifikacji pacjenta do leczenia rehabilitacyjnego

41 System musi umożliwiać generowanie formularza zgody pacjenta na zabieg.

42 System musi umożliwiać generowanie elektronicznego zlecenia wykonania badań laboratoryjnych i

diagnostycznych.

43 System musi umożliwiać generowanie elektronicznego zlecenia wykonania badań histopatologicznych do

zakładu histopatologii.

44 System musi umożliwiać przeglądanie w trakcie przyjmowania pacjenta wyników zleconych badań

laboratoryjnych i diagnostycznych.

45 System musi umożliwiać ewidencję realizowanych procedur medycznych.

46 System musi umożliwiać wyznaczenie produktu rozliczeniowego ze wspomaganiem rozliczeń specjalistycznych

świadczeń ambulatoryjnych w ramach jednorodnych grup pacjentów (JGP) w zakresie: kwalifikacji świadczenia

do grupy, grupowania alternatywne w zależności od wprowadzonych istotnych wartości.

47 System musi umożliwiać podpowiadanie, skierowania z ostatniej wizyty pacjenta podczas rejestrowania danych

kolejnej wizyty w terminarzu.

48 System musi umożliwiać , podczas rezerwowania wizyty, zmianę czasu trwania wizyty np. z 10 minut do 15. Po

zatwierdzeniu wpisu, w terminarzu powinien pojawić się komunikat o tym, że wizyta jest przedłużona.

49 System musi umożliwiać obsługę kart diagnostyki i leczenia onkologicznego (DiLO) w zakresie:

- Możliwość przyjęcia pacjenta na podstawie karty DiLO,

- Weryfikacja zgodności danych oraz kompletu danych niezbędnych do przyjęcia pacjenta na podstawie karty

DiLO, w tym tryb przyjęcia, numer karty, etap realizacji karty,

- Możliwość założenia karty DiLO w trakcie trwania świadczenia,

- Możliwość założenia kolejnej karty DiLO pacjenta dla drugiej grupy rozpoznań bez konieczności zamykania

aktywnej karty,

- Możliwość zablokowania zakładania kilku aktywnych kart DiLO dla pacjenta,

- Możliwość wydruku karty DiLO w wybranym trybie: tylko strony dot. obsługiwanego etapu karty, wszystkie

strony, objaśnienia,

- Możliwość realizacji kilku etapów karty DiLO podczas jednego świadczenia,

- Możliwość zamknięcia karty DiLO podczas realizacji świadczenia,

- Możliwość anulowania wprowadzonej karty DiLO,

- Możliwość usunięcia informacji o realizacji etapu karty DiLO w ramach świadczenia bez konieczności

usuwania całej karty,

- Podgląd listy świadczeń, w ramach których następuje realizacja kolejnych etapów obsługi karty DiLO.

50 System musi umożliwiać generowanie raportu pacjentów, u których upłynął 6 miesięczny okres opieki w AOS

po wykonanych w oddziałach zabiegach operacyjnych – analiza odległych skutków zabiegów (raport zawiera

minimum: dane pacjenta, datę i rodzaj wykonanego zabiegu, datę rozpoczęcia opieki w AOS, wykonane

Strona 104 z 204

procedury w poradni.

7.1.1.32 Gabinet POZ

Lp. Opis wymagania

1

System musi umożliwiać uzupełnienie dokumentów:

karta wizyty

oświadczenie pacjenta

wniosek o udzielenie świadczenia poza systemem powszechnego ubezpieczenia zdrowotnego

parametry życiowe

pomiar glukozy

doraźne podanie leku lub zużycie sprzętu

wyniki badań diagnostycznych

zaświadczenie o stanie zdrowia.

2. System musi umożliwiać obsługę dedykowanych dokumentów POZ

- Informacja dla lekarza kierującego/POZ

- Skierowanie na realizację zleceń pozostających w zakresie pielęgniarki/położnej POZ

- Wniosek o akceptacje realizacji transportu sanitarnego w POZ

- Indywidualna karta opieki pielęgniarskiej w POZ

- Dane o funkcjonalności świadczeniobiorcy POZ.

4. System musi umożliwiać uzupełnianie dokumentu wywiad środowiskowo-rodzinny POZ.

5. System musi umożliwiać uzupełnianie dokumentów związanych z zakażeniem.

6. System musi umożliwiać podgląd ostatnich wizyt.

7. System musi umożliwiać podgląd wyników badań, w przypadku wyników badań laboratoryjnych przeglądanie w

formie tabelarycznej z oznaczeniem wartości odstających oraz w formie wykresu z możliwością wyboru

parametrów znajdujących się na wykresie.

8. System musi umożliwiać obsługę recepty i e-recepty:

podgląd wcześniejszych e-recept pacjenta

podgląd leków stałych pacjenta

tworzenie recept na leki recepturowe

pogląd stanu numerów recept

podgląd wcześniejszych recept pacjenta

możliwość przepisania recepty wcześniej wystawionej.

9. System musi umożliwiać ewidencjonowanie szczepień w zakresie dokumentacji:

Strona 105 z 204

- wypełnienie kwestionariusza wywiadu przesiewowego przed szczepieniem dorosłych

- wypełnienie kwestionariusza wywiadu przesiewowego przed szczepieniem dzieci i młodzieży

- oświadczenie opiekuna – szczepienia.

10. System musi umożliwiać ewidencjonowanie informacji dotyczących szczepienia w zakresie:

data podania

nazwa szczepienie

nr serii szczepienia

data ważności

personel wykonujący

personel zlecający.

11. System musi umożliwiać ewidencjonowanie informacji dotyczących wywiadu przesiewowego przed szczepieniem

dzieci i młodzieży w zakresie:

- data i godzina badania

- osoba wypełniająca

- ankieta badania przesiewowego

- wpisu w książeczce szczepień

- wpisu w karcie uodpornienia.

12. System musi umożliwiać podgląd historii szczepień w historii choroby pacjenta

13. System musi umożliwiać przeglądanie oraz odnotowania informacji o stałych lekach i chorobach pacjenta

bezpośrednio z gabinetu.

14. System musi umożliwiać przeglądanie z poziomu gabinetu poprzednich oraz zaplanowanych wizyt pacjenta.

15. System musi umożliwiać przeglądanie pełnej historia choroby pacjenta w zależności od uprawnień użytkownika.

16. System musi umożliwiać dostęp do podglądu wyników badań. W przypadku wyników badań laboratoryjnych w

formie tabelarycznej powinny zostać oznaczane wartości odstające.

17. System musi umożliwiać wystawianie zleceń, skierowań, recept.

18. System musi umożliwiać ewidencjonowanie danych wizyty (potwierdzenie obecności pacjenta, przegląd,

wprowadzanie i modyfikacja danych o wizycie), przeglądu i edycji (stosownie do posiadanych uprawnień) danych

pacjenta.

19. System musi umożliwiać prowadzenia dokumentów dot. standardu okołoporodowego stosowanego w POZ przez

położne środowiskowe:

- Ankieta satysfakcji kobiet objętych opieką okołoporodową.

- Edynburska skala depresji poporodowej (EPDS).

- Gromadzenie danych - daty wizyt.

- Karta opieki nad kobietą ciężarną - edukacja prowadzona przez położną (POZ).

- Plan porodu.

Strona 106 z 204

- Program edukacji przedporodowej.

20. System musi umożliwiać prowadzenie siatki centylowej.

21. System musi umożliwiać uzupełnianie dokumentacji medycznej POZ wymaganej dla pielęgniarki/pielęgniarki

środowiskowej/położnej.

22. System musi umożliwiać wystawianie karty zgonu.

23. System musi umożliwiać wystawianie wniosku na zaopatrzenie w środki medyczne.

24. System musi umożliwiać generowanie elektronicznego skierowania na zabiegi rehabilitacyjne oraz przesyłanie

informacji zwrotnych z fizykoterapii fizjoterapii do lekarza wystawiającego zlecenie co do przeprowadzonego

badania i kwalifikacji pacjenta do leczenia rehabilitacyjnego.

7.1.1.33 Obsługa kolejek

Lp. Opis wymagania

1. System musi umożliwiać rejestrowanie i obsługę kolejek oczekujących, w tym również w odniesieniu do wizyt

rejestrowanych z wykorzystaniem portalu pacjenta zgodnie z wymogami prawa.

2. System musi umożliwiać automatyczną numeracji wpisów na listy oczekujących.

3. System musi umożliwiać zapis do kolejki na dowolny okres w przód i umożliwiać konfigurację kolejek w tym

zakresie.

4. System w zakresie kolejek oczekujących typu "K" (na komórkę) musi zapewniać możliwość prowadzenia i

sprawozdawania kolejek oczekujących i nie wymaga dodatkowej konfiguracji w tym zakresie dla tych typów

komórek (według NFZ), dla których prowadzenie kolejek jest wymagane (dodawanie mapowania dla nowego

miejsca realizacji świadczeń według NFZ udostępnia tworzenie kolejki w jednostkach organizacyjnych

Zamawiającego, dla których zdefiniowano mapowanie na dowolny okres w przód, ponowne wczytywanie

mapowania nie zmienia określonego wcześniej terminu dostępności kolejki).

5. System musi umożliwiać możliwość konfiguracji, jakie kolejki typu "P" (na procedurę) w jakich jednostkach

organizacyjnych Zamawiającego (w powiązaniu z kodem technicznym miejsca realizacji w NFZ) będą prowadzone

i sprawozdawane.

6. System w ramach uprawnień użytkowników musi zapewniać możliwość:- ewidencji danych w zakresie kolejek

oczekujących wyłącznie dla zasobów udostępnionych użytkownikowi w ramach uprawnień odnośnie struktury

organizacyjnej,- blokadę dokonywania nowych wpisów i korekty wpisów w zakresie kolejek oczekujących, w tym

daty i godziny dokonania wpisu do kolejki skutkujących zmianą danych sprawozdawczych w zakresie kolejek

oczekujących za już sprawozdany okres, z wyłączeniem użytkowników uprawnionych do dokonywania takich

operacji.

7. System musi umożliwiać prowadzenie ewidencji wpisów odnośnie kolejek oczekujących wyłącznie dla świadczeń

planowanych do realizacji w ramach finansowania przez NFZ.

8. System musi umożliwiać zapis tego samego pacjenta do wielu różnych kolejek oczekujących.

9. System musi umożliwiać zmiany planowanej daty przyjęcia pacjenta wraz z zapamiętaniem historii przesunięć

pacjenta na liście oczekujących oraz ewidencjonuje dane osoby dokonującej zmiany z informacją o powodzie jej

dokonania (według słownika) zgodnie z wymogami prawa.

10. System musi umożliwiać skreślenie pacjenta z listy oczekujących wraz z podaniem daty i powodu skreślenia

Strona 107 z 204

(według słownika) oraz osoby dokonującej skreślenia.

11. System musi umożliwiać prowadzenie i rozszerzanie słownika powodów skreślenia pacjenta z list oczekujących.

12. System musi umożliwiać przegląd aktualnego oraz archiwalnego stanu list oczekujących, w tym z archiwizacją

raportów przesyłanych do NFZ.

13. System musi umożliwiać wydruk i generowanie (do formatu csv,xls) raportu z zakresu listy oczekujących

zawierającego wszystkie wymagane prawem elementy.

14. System musi umożliwiać wydruk i generowanie (do formatu csv,xls) zbiorczego raportu z zakresu list oczekujących

dla określonego okresu sprawozdawczego (miesiąca, według aktualnego stanu w ewidencji) lub raportu

przekazanego do NFZ (stan przekazany do NFZ w danym raporcie), zawierającego w szczególności dane:- nazwa

miejsca wykonywania usług,- kod techniczny miejsca wykonania usług,- lokalizacja (Koszykowa, Żeromskiego),-

Kod procedury,- kategoria medyczna,- liczba oczekujących,- średni rzeczywisty czas oczekiwania,- liczba osób

skreślonych w danym miesiącu,- liczba osób skreślonych w danym miesiącu z powodu wykonania świadczenia,-

liczba osób skreślonych w ostatnich 3 miesiącach z powodu wykonania świadczenia.

15. System musi umożliwiać automatycznągenerowanie na podstawie zaewidencjonowanych danych tygodniowych

raportów sprawozdawczych w zakresie list pacjentów oczekujących odnośnie pierwszych wolnych terminów

według obowiązującego formatu XML z możliwością archiwizacji i przeglądania tych raportów w Systemie.

16. System musi umożliwiać ręczną modyfikację raportów w zakresie list oczekujących przed ich wysłaniem do NFZ.

17. System musi umożliwiać ewidencjonowanie faktu realizacji świadczeń z kolejki po stronie jednostek

organizacyjnych, do których pacjenci oczekują, jak i przez rejestracje.

18. System musi umożliwiać dostęp do funkcjonalności kolejek oczekujących niezależnie, z modułów: rejestracji,

gabinetów i pracowni, stosownie do nadanych uprawnień.

19. System w przypadku wystąpienia błędu w synchronizacji danych z systemem AP-KOLCE musi zapewnić

możliwość generowanie ostrzeżeń dostępnych dla użytkownika dokonującego edycji informacji.

20. System dla wpisów do kolejki, które nie zostały zsynchronizowane z systemem AP-KOLCE musi prezentować

informację o braku takiej synchronizacji oraz przyczynie takiego stanu.

21. Oferent przy wsparciu Zamawiającego zapewni synchronizację danych dotyczących kolejek oczekujących pomiędzy

wdrażanym Systemie i systemem AP-KOLCE w zakresie uzgodnionym z Zamawiającym w trakcie analizy

przedwdrożeniowej.

7.1.1.34 Badania profilaktyczne

Lp. Opis wymagania / punktacja

1. System musi umożliwiać implementację dedykowanych raportów pozwalających na profilowanie pacjentów wg

założonych kryteriów. Generator ten powinien pozwalać na samodzielne zakładanie warunków wyszukiwania

pacjentów wg wszystkich możliwych kombinacji i zakresów. Po wygenerowaniu konkretnego zapytania system

powinien zwracać listę pacjentów spełniających założone kryteria.

2. System musi umożliwiać wydruk lub zapis w formacie .doc / .xls / .csv wygenerowanej lista pacjentów.

3. System musi umożliwiać definiowanie dedykowanych, modyfikowanych przez użytkowników, pism kierowanych

do odpowiedniej grup pacjentów. Wygenerowane pismo powinno zawierać dane pacjenta: Imię, Nazwisko,

Strona 108 z 204

PESEL, adres zamieszkania i korespondencyjny.

4. System musi umożliwiać z poziomu portalu pacjenta definiowanie ankiet, na podstawie których możliwe będzie

profilowanie pacjentów.

5. System musi umożliwiać z poziomu portalu pacjenta podgląd informacji o zbliżających się terminach badań i

akcjach profilaktycznych.

6. System musi umożliwiać z poziomu rejestracji odnotowanie informacji, iż wizyta będzie związana z badaniem

profilaktycznym. W terminarzu pacjent powinien być rozróżniony w czytelny sposób np. innym kolorem.

7. System musi umożliwiać wygenerowanie raportów związanych z udzielonymi świadczeniami w ramach badań

profilaktycznych.

Lp. Laboratorium / Diagnostyka obrazowa / Sterylizacja

Zamawiający wymaga integracji systemu HIS z systemem LIS firmy MARCEL (analityka, toksykologia) oraz z

systemem Delphyn wykorzystywanym w laboratorium. Zamawiający również wymaga, aby w cenie zaproponowanego

rozwiązania były wszystkie koszty leżące po stronie oferenta wymagane do integracji z minimum 4 zewnętrznymi

jednostkami wykonującymi badania z zakresu patomorfologii oraz mikrobiologii.

Integracja musi opierać się co najmniej o standard HL7 wersja 2.3. System HIS musi wysyłać zlecenia na badania

laboratoryjne ze wszystkimi danymi wymaganymi prawem (dane osobowe i adresowe pacjenta, dane jednostki

kierującej, dane lekarza kierującego, listę badań, dane o pobraniu materiału itp.). System HIS musi odebrać co najmniej

wynik badania analitycznego i mikrobiologicznego. System HIS musi odebrać informację o przyjęciu

materiału/rozpoczęciu realizacji badania laboratoryjnego. Zamawiający wymaga integracji systemu HIS z systemem

PACS/RIS firmy PIXEL.

Integracja musi opierać się co najmniej o standard HL7 wersja 2.3. System HIS musi wysyłać zlecenia na badania

diagnostyczne ze wszystkimi danymi wymaganymi prawem (dane osobowe i adresowe pacjenta, dane jednostki

kierującej, dane lekarza kierującego, listę badań, itp.). System HIS musi odebrać co najmniej link do badania

obrazowego oraz wynik badania obrazowego. Integracja musi obsługiwać zmiany danych demograficznych pacjenta

wysyłane z HIS od PACS/RIS oraz uzupełnienia lub zmiany wyników opisowych wysyłane z RIS do HIS.

Zamawiający wymaga integracji systemu HIS z systemem do obsługi sterylizacji MEDOK.

Integracja musi uwzględniać następujący obieg informacji:

1. przekazywanie informacji o wysterylizowanym materiale użytym do zabiegów do dokumentacji medycznej

pacjenta, 2. przegląd dokumentacji archiwalnej opisującej przebieg ścieżki dekontaminacji konkretnego materiału w powiązaniu

z dokumentacją medyczną pacjenta, 3. funkcja przypisywania pakietów do poszczególnych zabiegów operacyjnych wraz z ewidencją poniesionych

kosztów, 4. podgląd bieżącego statusu zestawu lub narzędzia (gdzie jest i co się z nim dzieje) dowolnego użytkownika materiału

sterylnego. 5. Tworzenie zleceń w systemie uwzględniająca pełny nadzór nad obiegiem zestawów i narzędzi, rozliczanie i korekty

zleceń. 6. Integracja personelu i jednostek organizacyjnych.

Strona 109 z 204

7.1.1.35 Zarządzanie aparaturą medyczną

Lp. Opis wymagania

1. System musi umożliwiać zarządzanie słownikami urządzeń medycznych.

2. System musi umożliwiać tworzenie grafików dla urządzeń medycznych.

3. System musi umożliwiać zarządzanie czasem dostępności urządzeń medycznych (dostępne godziny,

planowanie przerw w pracy).

4. System musi umożliwiać w trakcie zlecania badania wskazania konkretnego aparatu powiązanego z

wykonaniem procedury.

5. System musi umożliwiać przypisanie urządzenia wraz z grafikiem do konkretnej jednostki.

6. System musi umożliwiać zdefiniowania usług realizowanych z wykorzystaniem urządzenia.

7. System musi umożliwiać przypisanie dedykowanych dokumentów, związanych z realizacją usług, do

urządzenia.

8. System musi umożliwiać równoległej rezerwacji wielu urządzeń w ramach jednego terminu.

9. System musi umożliwiać ustalenie limitu jednoczesnych wykonań wybranych usług w ramach jednego

terminu.

10. System musi umożliwiać określenie wymagalności urządzeń dla realizacji danej usługi.

11. System musi umożliwiać nałożenie blokady na wyłączność danego urządzenia dla danego lekarza w

określonych godzinach.

12. System musi umożliwiać 24-godzinne rezerwacje na sprzęt (np. holter).

13. System musi umożliwiać generowania raportu związanego liczbą badań na zadany okres w trakcie których

zostało wykorzystane urządzenie.

14. System musi umożliwiać wydruk listy badań na wybrany dzień zarezerwowanych na wybrane urządzenie.

15. System musi umożliwiać generowanie zestawienia informującego o ilości wykonań usług różnego rodzaju na

wybranym urządzeniu.

16. Zarządzanie i administracja

- Możliwość zarządzania słownikami (kategorie, nazwy, czynności okresowe, producenci, statusy

zleceń, miasta, województwa, miejsca realizacji, właściciele).

- Możliwość zarządzania strukturą - jednostki, kody, skróty, godziny otwarcia oraz wprowadzania

informacji o przerwach w pracy jednostek z możliwością raportowania w zestawieniach czasu pracy

urządzeniach.

- Logi zdarzeń: na karcie urządzenia, zlecenia, firmy są zapisywane chronologicznie informacje o

zmianach wprowadzonych w danym elemencie wraz z informacją o osobie zmiany te

wprowadzającej oraz dacie edycji.

- Podział na urządzenia medyczne, techniczne (z podziałem na słownikowane podkategorie), budynki

oraz informatyczne i oprogramowanie.

- Możliwość dołączania skanów dokumentacji do każdego urządzenia;

- Możliwość odnotowywania kosztów napraw oraz przeglądów z możliwością podglądu łącznej sumy

kosztów napraw i przeglądów oraz możliwość osobnego podglądu kosztów tylko napraw lub tylko

przeglądów dla danego urządzenia;

- Konfigurowalny obieg informacji z określaniem widoczności elementów dla poszczególnych

użytkowników oraz projektowaniem ścieżki zleceń oraz wniosków zakupowych poprzez

wbudowany konfigurator z ustawianiem następujących elementów:

o wymuszanie edycji określonych elementów na poszczególnych etapach sprawy dla

wybranych grup użytkowników;

o projektowanie przejść pomiędzy kolejnymi etapami sprawy;

o automatyzacja procesów zmian statusów po wykonaniu danych czynności;

Strona 110 z 204

o wymagalność podania daty;

o pełna obsługa kodów kreskowych oraz kodów QR w tym pielęgnowanie i generowanie lub

kreskowych dla urządzeń z możliwością ich wydruku w określonych przez Administratora

formatach.

7.1.1.36 Transport medyczny

Lp. Opis wymagania

1. System musi umożliwiać utworzenie zlecenia na transport sanitarny.

2. System musi umożliwiać wprowadzenie w ramach dokumentu zlecenia na transport sanitarny następujących

danych (minimum):

- miejsce pobytu pacjenta (nazwa podmiotu leczniczego, ulica, miasto)

- miejsce docelowe transportu (nazwa podmiotu leczniczego, ulica, miasto, informacja z kim zostało

uzgodnione przyjęcie, telefony kontaktowe)

- informacja dotycząca ubezpieczenia (ZUS, KRUS, brak, inne)

- opis stanu pacjenta

- oświadczenie lekarza opiekującego się pacjentem (pole słownikowe)

- potrzeba zachowania ciągłości leczenia

- konieczność podjęcia natychmiastowego leczenia w podmiocie leczniczym

- transport jest transportem powrotnym w rozumieniu art. 41 Ustawy o świadczeniach opieki

zdrowotnej finansowanych ze środków publicznych

- transport jest wykonywany w innym celu niż wymienione wyżej

- cel transportu (kryteria medyczne)

- telefon kontaktowy.

3. System musi umożliwiać wprowadzenie w ramach dokumentu zlecenia na transport sanitarny następujących

danych (minimum):

- rozpoznanie

- stopień niepełnosprawności pacjenta (z następowym automatycznym określeniem poziomu odpłatności

pacjenta za transport sanitarny zgodnie z przepisami prawa)

- miejsce odbioru pacjenta

- data odbioru pacjenta

- godzina odbioru pacjenta

- pozycja

- miejsce transportu pacjenta

- cel przewozu:

- konieczność podjęcia natychmiastowego leczenia w zakładzie opieki zdrowotnej

- potrzeba kontynuacji leczenia (kontynuowanie leczenia w danym zakładzie lub przekazania do

dalszego leczenia w innym zakładzie)

- dysfunkcja narządu ruchu uniemożliwiająca korzystanie ze środków transportu publicznego (w celu

przejazdu na leczenie do najbliższego zakładu opieki zdrowotnej udzielającego świadczeń we

właściwym zakresie i z powrotem)

- inne wyżej nie wymienione.

4. System musi umożliwiać utworzenie zlecenia przewozu medycznego.

Strona 111 z 204

5. System musi umożliwiać wprowadzenie w ramach dokumentu zlecenia przewozu medycznego następujących

danych (minimum):

- data zgłoszenia

- data i godzina przewozu

- miejsce docelowe

- rodzaj przewozu:

- międzyszpitalny

- materiały diagnostyczne

- krew/preparaty krwi

- inny

- rodzaj samochodu:

- karetka reanimacyjna

- z miejscami siedzącymi

- z miejscami do leżenia

- sposób realizacji przewozu:

- przejazd w jedną stronę – tylko tam

- przejazd tam i z powrotem

- informacje o pacjencie:

- chodzący/sprawny

- siedzący – niechodzący

leżący – niechodzący

6. System musi umożliwiać utworzenie zlecenia na przewóz asekuracyjny

7. System musi umożliwiać wprowadzanie w ramach dokumentu zlecenia przewozu asekuracyjnego

następujących danych (minimum):

- data i godzina zlecenia

- miejsce przeznaczenia pacjenta

- podstawowe rozpoznanie medyczne stanowiące wskazanie do przewozu (kod ICD10)

- niezbędne informacje o pacjencie dla ratownika/lekarza asystującego w czasie transportu

- zalecenia na czas transportu wpisywane bezpośrednio lub na dodatkowym formularzu:

- monitorowanie serca

- pulsoksymetria

- respirator

- tlenoterapia

- monitorowanie RR

- płynoterapia

- odsysanie treści żołądka

- unieruchomienie

- podawanie leków

- rodzaj asekuracji

- ‘P’ z ratownikiem

- ‘S’ lekarz i ratownik

8. System musi umożliwiać generowanie i przeglądu raportu zleceń na transport

9. System musi umożliwiać ewidencję w ramach raportu zleceń na transport następujących danych (minimum):

- dane pacjenta, którego zlecenie dotyczy

- data i godzina zlecenia

Strona 112 z 204

- jednostka zlecająca

- lekarz zlecający.

10. System musi umożliwiać filtrację raportu po dacie zlecenia – domyślnie prezentowane są dane dotyczące

zleceń z aktualnego dnia.

11. System musi umożliwiać filtrację raportu po imieniu i nazwisku konkretnego pacjenta.

12. System musi umożliwiać filtrację raportu po jednostce zlecającej.

13. System musi umożliwiać wydruk z poziomu raportu konkretnego zlecenia transportu.

14. System musi umożliwiać automatyczne przenoszenie danych dotyczących zleceń transportu do modułu

rozliczeń.

15. System musi umożliwiać na podstawie uzupełnionego dokumentu zlecenia transportu generowanie

odpowiedniej procedurę ICD9 bez konieczności ręcznego kopiowania tych danych.

Lp. Dializy

1. Pacjent dializowany

System zawiera podgląd pacjentów dializowanych – w nagłówku prezentowane są podstawowe dane

(minimum):

- data pierwszej dializy

- tryb prowadzenia pacjenta

- dostęp naczyniowy

- data ostatniej dializy

- lekarz realizujący

- stężenie hemoglobiny na ostatniej dializie

System prezentuje listę wszystkich odbytych dializ z opcją przekierowania do szczegółów dializ

System zapewnia możliwość przypisania, edycji i wyświetlania stałych leków pacjenta

System zapewnia możliwość podglądu wyników badań w formie wykresów i tabelarycznie

System zapewnia możliwość automatycznego wyliczania wskaźników URR i SpKt/V na podstawie ostatnich

wyników badań

2. Planowanie dializy

System zapewnia możliwość kopiowania zaplanowanych dializ dla pacjentów z tygodnia bieżącego na

kolejny.

System zapewnia możliwość automatycznego wykorzystania zlecenia przygotowanego na oddziale

System zapewnia możliwość podglądu grafiku dla kilku dni jednocześnie

System zapewnia możliwość rezerwacji wolnych terminów na dializy w oparciu o dostępne zmiany i

dializatory.

System zapewnia możliwość dostępu do listy zarejestrowanych pacjentów w danym dniu.

3. Realizacja dializy

System zapewnia możliwość odnotowania realizacji dializy w systemie.

System zapewnia możliwość zapisu dializy wraz z formularzem dializy

System zapewnia możliwość ewidencji danych pacjenta przed dializą (minimum):

Strona 113 z 204

- waga należna

- waga przed HD

- waga po HD

- temperatura ciała

- ciśnienie krwi

- ograniczenia funkcjonalne

- ultrafiltracja

- ocena stanu pacjenta lekarska i pielęgniarska

System zapewnia możliwość ewidencji parametrów dializy (minimum):

- dane dotyczące stanowiska: dane aparatu, przebieg techniczny, obroty pompy i koncentrat

- dane preparatu

- użyty dializator

System zapewnia możliwość przypisania personelu realizującego

System zapewnia możliwość ewidencji szczegółowych danych dotyczących przebiegu dializy (data początku

i końca wraz z godziną, RR, tętno itp.)

System zapewnia możliwość ewidencji podanych leków

System zapewnia możliwość wydruku protokołu hemodializy

System zapewnia możliwość tworzenia szablonów stałych treści

System zapewnia możliwość ewidencji zużycia leków

System zapewnia możliwość wydruku protokołu hemodializy i karty informacyjnej

System zapewnia możliwość wizualizacji graficznej przebiegu dializy na terminarzu

4. System umożliwia wystawianie e-recept dla dializowanych pacjentów.

7.1.1.37 Medycyna pracy

Lp. Opis wymagania

1. System musi umożliwiać prowadzenie pełnej historii m.in. badań wstępnych, okresowych, kontrolnych.

2. System musi umożliwiać prowadzenie formularza Wywiad Lekarski.

3. System musi umożliwiać prowadzenie formularza Wywiad Zawodowy, zawierającego m.in. pola:

- Jakie stanowisko pracy/nauki?

- Czy badany uległ wypadkowi w pracy?

- Opis skutków wypadku w pracy,

- Czy badanemu przyznano świadczenie rentowe?

- Powód przyznania świadczenia rentowego,

- Czynniki szkodliwe/uciążliwe na stanowisku pracy/nauki,

- Informacja o chorobach zawodowych?

- Czy lekarz wnioskował o zmianę stanowiska pracy/nauki ze względu na stan zdrowia badanego?

- Stopień niepełnosprawności, data orzeczenia, przyczyna.

4. System musi umożliwiać zbieranie m.in. takich danych o badanym z opcją zaznaczania tak/nie oraz ręcznego

wpisywania treści w pola opisowe:

- Czy badany przechodził zabiegi operacyjne?

Strona 114 z 204

- Spis przechodzonych operacji

- Czy badany przyjmuje leki?

- Spis przyjmowanych leków,

- Czy badany pali obecnie/palił w przeszłości tytoń? (przez ile lat i ile dziennie)

- Przyjmowania używek, jakich?

5. System musi umożliwiać wprowadzanie m.in. następujących danych o badanym:

- Nazwisko i imię,

- Płeć,

- PESEL,

- Adres zamieszkania,

- Rodzaj badania,

- Objęty opieką jako pracownik/praca nakładcza/pobierający naukę/na własny wniosek/ uczeń/doktorant,

- Dane identyfikacyjne miejsca pracy/pobierania nauki.

6. System musi umożliwiać wprowadzenie m.in. następujących informacji:

- czynnikach szkodliwych na stanowisku pracy/miejscu pobierania nauki.

7.1.2 Część biała eUsługi

7.1.2.1 E-Zwolnienia (eZLA)

Lp. Opis wymagania

1. System musiumożliwiać wystawianie zwolnień przy działającym połączeniu do ZUS.

2. System musi umożliwiać wczytanie certyfikatu ZUS z poziomu aplikacji.

3. System musi umożliwiać autoryzację certyfikatemcertyfikatami ZUS, em ePUAP oraz podpisem kwalifikowanym

osoby uprawnionej. .

4. System musi umożliwiać pobieranie danych zakładów pracy.

5. System musi umożliwiać automatyczne uzupełnienie danych pacjenta na zwolnieniu.

6. System musi umożliwiać wysyłkę zwolnienia do ZUS.

7. System musi umożliwiać wydruk zwolnienia.

8. System musi umożliwiać potwierdzenie UPP.

9. System musi umożliwiać wystawienie więcej niż jednego zwolnienia (np. do różnych zakładów).

10. System musi umożliwiać wystawienie wstecznego zwolnienia.

11. System musi umożliwiać anulowania zwolnienia.

12. System musi umożliwiać unieważnienie zwolnienia.

13. System musi umożliwiać przegląd wszystkich wystawionych zwolnień.

14. System musi umożliwiać automatyczne kopiowanie informacji o wystawionym zwolnieniu do dokumentacji

medycznej pacjenta.

Strona 115 z 204

7.1.2.2 E-Usługi – Portal pacjenta

Lp. Opis wymagania / punktacja

1. e-Usługi dostępne w ramach Portalu pacjenta to zestaw aplikacji, które umożliwiają interakcję z użytkownikiem (szczególnie pacjentem i lekarzem) metodą zdalną, między innymi za pośrednictwem Internetu.

2. Wszystkie aplikacje wchodzące w skład Portalu pacjenta (Aplikacje) muszą korzystać z tej samej bazy danych (w rozumieniu zbioru danych i modelu danych) co system centralny, ale nie mogą łączyć się bezpośrednio do tej bazy, a jedynie poprzez dodatkowy zabezpieczony interfejs komunikacji (np. WebServices).

3. Aplikacje dostępne dla pacjentów w Internecie do komunikacji z systemem centralnym w intranecie placówki wykorzystują zabezpieczony kanał szyfrowanej komunikacji (podniesienie bezpieczeństwa danych), jak VPN i/lub HTTPS.

4. Wszystkie aplikacje muszą być zarządzane przez jeden moduł administracyjny dla całego systemu centralnego w zakresie zarządzania dokumentacją medyczną i grafikami dostępności.

5. Wielojęzyczność

Portal jest przystosowany do obsługi różnych języków, w zakresie zarówno elementów stałych strony WWW, jak i zasobów przechowywanych w bazie danych (np. typy poradni, specjalizacje lekarzy, itp.) wraz z zapamiętywaniem wybranego przez operatora języka. Wykonawca wraz z aplikacją dostarcza tłumaczenie elementów stałych strony WWW na wybrany język oraz konfiguruje system centralny w taki sposób, aby Zamawiający mógł samodzielnie wprowadzać tłumaczenia zasobów w bazie danych. (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

Portal nie jest przystosowany do obsługi różnych języków, w zakresie zarówno elementów stałych strony WWW, jak i zasobów przechowywanych w bazie danych (np. typy poradni, specjalizacje lekarzy, itp.) wraz z zapamiętywaniem wybranego przez operatora języka

7.1.2.3 E-Usługi – rejestracja

Opis wymagania

1. System musi umożliwiać dokonywanie rezerwacji wizyt przez pacjenta metodą zdalną, za pośrednictwem Internetu.

2. System musi umożliwiać pacjentowi samodzielne zakładanie indywidualnego kontana portalu. Do założenia konta tymczasowego pacjent musi podać następujące dane: imię, nazwisko, PESEL (tylko w przypadku posiadania obywatelstwa polskiego), typ i numer dokumentu potwierdzającego tożsamość oraz adres e-mail. Po zatwierdzeniu danych portal wysyła kod aktywacyjny na podany przez pacjenta adres e-mail. Wprowadzenie i zatwierdzenie otrzymanego kodu powodują automatyczne aktywowanie konta pacjenta. Tak założone konto ma status konta tymczasowego aż do momentu jego aktywowania przez upoważnionego pracownika jednostki, na podstawie wniosku dostarczonego przez pacjenta. Wniosek drukowany jest bezpośrednio z aplikacji Portalu po aktywowaniu konta tymczasowego.

3. Konto tymczasowe pozwala pacjentowi na przeglądanie grafików pracy poszczególnych lekarzy oraz pozwala na rezerwację w danym czasie tylko jednego terminu wizyty.

4. Pacjent korzystając z przygotowanej witryny internetowej może się zalogować, wybrać na podstawie różnych kryteriów interesującą go wizytę i zarezerwować ją.

Strona 116 z 204

5. Informacja o dokonanej rezerwacji trafia do systemu centralnego, gdzie wizyty z e-Rejestracji są wyraźnie oznaczone. Jednocześnie moduł korzysta z definicji tych samych grafików co system centralny.

6. Rejestracja przez Internet ma taki sam charakter i status jak rejestracja dokonana bezpośrednio w placówce medycznej.

7. Funkcja pozwala pacjentowi na wyszukanie wolnych terminów wizyt wg kryteriów: lekarza lub poradni, daty wizyty oraz czasu jej trwania (od do). Do wyszukania najbliższej wolnej wizyty niezbędne jest podanie lekarza lub poradni.

8. Po wybraniu jednego z głównych kryteriów (lekarza lub poradni) lista wyboru dla pozostałych kryteriów zawęża się (np. po wybraniu poradni pediatrycznej w polu lekarz mamy do wyboru jedynie lekarzy pediatrów).

9. Po wprowadzeniu kryteriów wyszukiwania funkcja wyświetla listę wszystkich wolnych wizyt spełniających kryteria wraz z informacjami o typie wizyty (typy wizyt np.: prywatna, POZ, medycyna pracy, itp. są definiowane przez operatora w systemie centralnym).

10. Portal udostępnia funkcję umożliwiającą pacjentowi przesłanie za jego pośrednictwem pliku zawierającego skierowanie (ustandaryzowany plik xml lub skan skierowania).

11. Po wybraniu terminu z listy funkcja udostępnia ekran, na którym ostateczne pacjent potwierdza wszystkie dane. W przypadku wybrania wizyty prywatnej, pacjent dodatkowo potwierdza fakt przyjęcia do wiadomości, że usługa nie jest refundowana.

12. Rejestracja za pośrednictwem portalu pacjenta może zostać ograniczona:

o do wybranych poradni, lekarzy oraz gabinetów,

o poprzez ustalenie liczby rezerwacji wprowadzanych przez pacjenta,

o poprzez ustalenie liczby dni jakie muszą upłynąć pomiędzy kolejnymi rezerwacjami do tej samej poradni.

13. Funkcja pozwala na zablokowanie możliwości rejestracji dla pacjenta z kontem tymczasowym.

14. Funkcja pozwala na zablokowanie możliwości rejestracji za pośrednictwem portalu dla pacjenta pierwszorazowego w danej poradni.

15. Funkcja pozwala na określenie procentowej puli grafika do wykorzystania przez e-Rejestrację.

16. Funkcja pozwala na blokadę rezerwacji dla pacjenta, który nie zjawił się na 3 kolejnych potwierdzonych wizytach.

17. Funkcja pozwala na blokadę rezerwacji do poradni POZ dla pacjenta, który nie posiada aktywnej deklaracji złożonej w placówce.

18. Wszyscy pacjenci mogą korzystać z tej samej puli dostępnych terminów z uwzględnieniem definiowanego przez operatora procentowego podziału puli grafika na rejestracje za pośrednictwem portalu oraz rejestracji w placówce medycznej.

19. Funkcja umożliwia zdefiniowanie okresu, w jakim pacjent musi potwierdzić zarezerwowaną wizytę (np. wizyty zarezerwowane na 7 dni przed terminem musza być potwierdzone od 4 do 2 dni przed wizytą, w przeciwnym przypadku rezerwacja jest anulowana).

20. Funkcja umożliwia określenie terminu (w dniach), w którym do pacjenta zostanie wysłane przypomnienie o

Strona 117 z 204

wizycie.

7.1.2.4 E-Usługi – Kolejka oczekujących

Opis wymagania

1. Funkcja umożliwia pacjentowi śledzenie statusu w kolejce oczekujących zdefiniowanej w oddziale, poradni, pracowni (e-Kolejka).

2. Pacjent ma możliwość przeglądania kolejek oczekujących – prowadzonych zgodnie z wymaganiami NFZ w tym zakresie oraz osobno statusów i historii pozostałych wizyt.

7.1.2.5 E-Usługi – Powiadomienia

Opis wymagania

1. Aplikacja pozwala na zdefiniowanie automatycznych powiadomień pacjenta o zbliżających się terminach wizyt oraz innych zdarzeniach medycznych (np. termin badania, wizyty, informacje o badaniach profilaktycznych) za pomocą 3 kanałów komunikacji: SMS, e-mail, wiadomości systemowe dostępne po zalogowaniu do Portalu pacjenta.

2. Funkcja pozwala na konfigurację formatu treści wiadomości do wysyłki, w tym użycie parametrów: imię i nazwisko pacjenta, numer pacjenta, data wizyty (dd-mm-yyyy), dzień wizyty (dd), miesiąc wizyty (numer w formacie mm lub słownie), rok wizyty (yyyy), godzina wizyty (HH:mm), nazwa krótka usługi.

3. Funkcja pozwala na definiowanie niezależnych szablonów wiadomości dla każdego typu usług /porad, z określeniem szablonu domyślnego.

4. Funkcja obsługuje format CSV dla pakietu dostarczanego dostawcy bramki SMS.

5 Funkcja pozwala na generowanie wiadomości tylko dla tych pacjentów, którzy wyrazili zgodę na ich otrzymywanie. Pacjent, za pośrednictwem portalu, ma możliwość zarządzania zgodami (na wysyłanie wiadomości poprzez e-mail lub SMS).

6 Funkcja zapisuje w bazie danych systemu wszystkie wysłane wiadomości wraz z datą ich wygenerowania. Wiadomości te są powiązane z wizytą, usługą, pacjentem oraz wykorzystanym szablonem wiadomości.

7 Funkcja posiada mechanizm kontroli przed ponowną wysyłką tego samego komunikatu.

8 Funkcja pozwala na określenie godziny oraz cykli w dniach, w jakich pakiety wiadomości będą generowane do wysyłki.

I. 9 Funkcja pozwala na określenie maksymalnej długości wiadomości SMS.

II. 10 Funkcja pozwala na generowanie wiadomości tylko do tych pacjentów, którzy posiadają uzupełniony w systemie numer telefonu komórkowego.

III. 11 Funkcja pozwala na określanie indywidualnie dla każdego pacjenta preferowanych kanałów komunikacyjnych w przypadku powiadomień o wizytach, badaniach, zbliżającym się terminie przyjęcia do placówki wg kolejki oczekujących, informacjach o badaniach profilaktycznych.

Strona 118 z 204

7.1.2.6 E-Usługi – Leki

Opis wymagania

1. Dla pacjentów i posiadających konto stałe funkcja pozwala na przesłanie za pośrednictwem portalu „zamówienia” na wystawienie recepty (e-Recepty) na kontynuację leczenia.

2. Funkcja pozwala pacjentowi na wybranie z listy leków, które były już mu wcześniej przepisywane podczas wizyty w danym podmiocie leczniczym, tych pozycji, których z dotyczy „zamówienie”.

3. Po zatwierdzeniu przez pacjenta wybranych leków, wykaz ten automatycznie trafia do osoby uprawnionej, która ma możliwość zatwierdzenia, wg własnego uznania, tych leków wskazanych przez pacjenta, które umieszczone zostaną są na recepcie. Zwrotnie pacjent otrzymuje informację o tym, które z wnioskowanych leków zostały umieszczone na recepcie.

7.1.2.7 E-Usługi – Dokumentacja

Opis wymagania

1. Aplikacja pozwala pacjentowi na przeglądanie kart HZiCh (poradnia), kart informacyjnych leczenia szpitalnego oraz innych udostępnionych pacjentowi przez dany podmiot leczniczy dokumentów. Portal obsługuje wyłącznie dokumentację podpisaną podpisem elektronicznym.

2. Po zalogowaniu pacjent może wyświetlić listę wszystkich udostępnionych mu dokumentów, ograniczyć listę na podstawie różnych kryteriów (lekarz, jednostka wykonująca) i pobrać na lokalny komputer interesujące go dokumenty. Funkcja nie umożliwia wysyłanie dokumentów poprzez e-mail.

3. Funkcja pozwala na ograniczenie wyświetlania HZiCh do wybranych usług.

7.1.2.8 E-Usługi – Wyniki

Opis wymagania

1. 1

1 Aplikacja pozwala pacjentowi na przeglądanie udostępnionych pacjentowi wyników badań laboratoryjnych. Portal wyświetla wyniki badań o statusie „zatwierdzone” w systemie centralnym (wydrukowane i zatwierdzone przez diagnostę laboratoryjnego).

2. 2 Po zalogowaniu pacjent może wyświetlić listę wszystkich udostępnionych mu wyników badań laboratoryjnych i ograniczyć listę na podstawie różnych kryteriów (nazwa badania, jednostka wykonująca) interesujące go wyniki.

3. Funkcja pozwala na ograniczenie wyświetlania wyników do wybranych badań.

7.1.2.9 E-Usługi – Ankiety

Opis wymagania

a. Aplikacja pozwala na obsługę ankiet wypełnianych przez pacjentów.

Strona 119 z 204

4. W systemie jest przygotowana jedna stała ankieta, administrator może wyłącznie przeglądać wzór, bez możliwości jego modyfikowania.

5. Po zakończonej wizycie w gabinecie pacjent otrzymuje komunikat informujący go o tym, że może on wypełnić ankietę. Powiadomienie wysyłane jest na adres e-mail.

6. Po zalogowaniu do Portalu, pacjent może wypełnić ankietę bezpośrednio w Portalu. Po zatwierdzeniu wypełnionej ankiety przez pacjenta, jest ona poddawana analizie.

7. Pacjent może przeglądać wypełnione przez siebie ankiety, jednak już bez możliwości wprowadzania zmian na ankietach zatwierdzonych.

8. Wyniki wypełnionych przez pacjentów ankiet prezentowane są w aplikacji administracyjnej.

9. Raporty z wynikami analizy mogą być generowane z możliwością określenia parametrów (np. poradnia, lekarz).

7.1.2.10 E-Usługi – Kontrahent

Opis wymagania

1. Moduł przeznaczony jest do wykorzystania przez personel jednostek współpracujących z Zamawiającym.

2. Funkcja pozwala na zakładanie kont dla personelu kontrahenta (dane osobowe) oraz określanie przynależności do danego kontrahenta.

3. Funkcja pozwala na określanie pacjentów związanych z danym kontrahentem.

4. Pracownik kontrahenta po zalogowaniu do portalu ma możliwość przeglądu listy usług realizowanych przez Zamawiającego na rzecz kontrahenta wraz z harmonogramami realizacji usług.

5. Pracownik kontrahenta ma możliwość zlecania realizacji, anulowanie zleceń lub zmiany terminu zaplanowanej usługi medycznej.

6. Funkcja pozwala na przeglądanie zleceń na usługi medycznych z wyróżnieniem stanu zlecenia (planowane, zrealizowane, anulowane).

7. Funkcja pozwala na wydruk raportu prezentującego liczby zrealizowanych usług w określonym czasie.

7.1.2.11 E-Usługi – Konsultacje

Opis wymagania

1 System umożliwia konfigurację zapewniającą użytkownikowi dostęp do dokumentacji medycznej pacjenta udostępnionej w celu konsultacji przez podmiot leczniczy z której pochodzi pacjent.

IV. 2 System umożliwia przeglądanie dokumentacji medycznej pacjenta z wykorzystaniem przeglądarki internetowej.

V. 3 Dokumentacja prezentowana w przeglądarce jest tożsama w zakresie treści i formy z dokumentacją prezentowaną w macierzystym systemie HIS.

VI. 4 Komunikator ma służyć do połączenia pomiędzy dwoma specjalistami np. lekarzami.

Strona 120 z 204

7.1.2.12 E- Dokumentacja

Lp. Opis wymagania

1. System musiumożliwiać bezpieczne gromadzenie elektronicznej dokumentacji medycznej.

2. System musi umożliwiać na wymianę dokumentacji z innymi podmiotami zgodnie z P1.

3. System musi umożliwiać uwierzytelniać użytkowników za pomocą unikatowego identyfikatora użytkownika i

niejawnego hasła.

4. System musi umożliwiać dostęp do dokumentacji medycznej pacjentów dla osób uprawnionych oraz posiadać

zabezpieczenia przed dostępem do dokumentacji przez osoby nieuprawnione.

5. System musi zabezpieczać dokumentację przed uszkodzeniem lub utratą.

6. System musi prowadzić dziennik zdarzeń, a wszystkie operacje dotyczące dokumentu są zapisywane w sposób

umożliwiający określenie kolejności działań i wykonawców czynności.

7. System musi posiadać repozytorium dokumentacji medycznej, które odpowiada za przyjmowanie, gromadzenie i

przetwarzanie dokumentacji medycznej.

8. Repozytorium powinno gwarantować zachowanie pełnej integralności i wiarygodności przechowywanej

dokumentacji.

9. System musi umożliwiać gromadzenie dokumentację w repozytorium w standardzie HL7CDA wraz z obsługą

poziomów poufności.

10. System musi umożliwiać dołączenie w repozytorium do dokumentu medycznego zestawu załączników dowolnych

typów (dokumentów tekstowych, grafik, PDF, itp…).

11. Repozytorium powinno umożliwiać pobranie dowolnego dokumentu o znanym identyfikatorze.

12. System musi posiadać mechanizm uprawnień uwzględniający kody poufności zawarte w dokumentach

medycznych i zabezpieczać przed dostępem do wyższych poziomów niż wynika z uprawnień użytkownika.

13. System musi umożliwiać eksport dokumentacji medycznej do formatów PDF lub XML wraz z zabezpieczeniem

hasłem.

14. System musi umożliwiać wydruk dokumentacji gromadzonej w repozytorium. W przypadku sporządzania

wydruku z dokumentacji medycznej pacjenta, kolejne strony wydruku muszą być automatycznie numerowane i

oznaczane co najmniej imieniem i nazwiskiem pacjenta, a poszczególne wpisy do dokumentacji opatrzone

oznaczeniem podmiotu, jednostki i komórki organizacyjnej w której udzielono świadczeń zdrowotnych oraz datą

i oznaczeniem osoby dokonującej wpisu.

15. System musi umożliwiać wersjonowanie dokumentów w repozytorium i umożliwiać ich aktualizację.

16. System musi umożliwiać przechowywanie dokładnej daty otrzymania każdego dokumentu.

17. System musi umożliwiać wybór transformaty (domyślna systemowa, zgodna z wytycznymi CSIOZ) zgodnie, z

którą mają być wyświetlane dokumenty.

18. System musi umożliwiać masowy import obsługiwanych dokumentów archiwalnych.

19. System musi umożliwiać podgląd załączników dokumentu.

Strona 121 z 204

20. System musi umożliwiać pobranie na dysk lokalny załączników dokumentu.

21. System musi (o ile nie wskazano inaczej) powinien zawsze prezentować najnowszą wersję dokumentu.

22. System musiumożliwiać prezentację wyników badań laboratoryjnych (dostarczonych w formie

ustrukturyzowanej) w postaci tabelarycznej. Wyniki wykraczające poza wartości referencyjne muszą być

odpowiednio zaznaczane.

23. System musiumożliwiać prezentację wyników badań laboratoryjnych (dostarczonych w formie

ustrukturyzowanej) z zaznaczonymi wartościami referencyjnymi.

24. System musi obsługiwać linki do zewnętrznych danych obrazowych.

25. System musi umożliwiać przechowywanie dokumentów w repozytorium w postaci zaszyfrowanej.

26. System musi umożliwiać rejestrowaniew rejestrze metadanych dokumentów przesłanych do repozytorium.

27. System musi umożliwiać przeszukiwanie dokumentacji medycznej na podstawie metadanych (lekarzy, typów

dokumentów, jednostki organizacyjnej, w której powstał dokumentu, na podstawie daty wytworzenia dokumentu).

28. System musi umożliwiać pełnotekstowe przeszukiwanie treści dokumentów w repozytorium.

29. System musi umożliwiać personelowi medycznemu przeszukiwanie listy pacjentów. Wyszukiwanie pacjentów

powinno odbywać się na podstawie nr PESEL, bądź imienia+nazwiska+daty urodzenia (podanych jednocześnie).

30. System musiumożliwiać udostępnianie dokumentacji pacjentom poprzez Portal Pacjenta.

31. System musi umożliwiać logowanie wszystkich operacji (wgląd w dokumentację, wydruki, udostępnienie) muszą

być logowane.

32. System musi umożliwiać logowanie udostępnień EDM poza system informatyczny, z odnotowaniem

następujących danych:

- data i godzina udostępnienia

- dane wnioskodawcy / systemu pobierającego dane

33. System musi obsługiwać standard HL7CDA R2 na najwyższym (trzecim) poziomie interoperacyjności.

7.1.3 Moduły raportująco-kalkulujące dla części białej, szarej i eUsług

7.1.3.1 System analityczny Business Intelligence (BI)

Lp. Opis wymagania

1. Narzędzie powinno umożliwiać raportowanie w oparciu o źródła OLAP.

2. Narzędzie powinno pozwalać na raportowanie w oparciu o źródła bazodanowe

3. Platforma raportowa powinna udostępniać funkcjonalność repozytorium raportów.

4. Aplikacja powinna pozwalać na przeszukiwanie repozytorium raportów i wyszukiwanie interesujących

Strona 122 z 204

użytkownika pozycji.

5. Struktura poszczególnych katalogów powinna być definiowana i zarządzana przez administratora.

6. Poszczególni użytkownicy powinni posiadać własne prywatne katalogi robocze, do których nie mają dostępu inni

użytkownicy bez stosownych uprawnień.

7. Aplikacja powinna pozwalać na definiowanie grup użytkowników oraz przydzielania im odpowiednich uprawnień.

8. Narzędzie powinno pozwalać na przydzielanie dostępu do poszczególnych analiz oraz nadawania praw do

modyfikacji bądź podglądu.

9. Aplikacja powinna pozwalać na dodawanie okresowych subskrypcji raportów oraz definiowania szczegółowego

harmonogramu wysyłania wiadomości email.

10. Aplikacja powinna pozwalać na załączenie widoku stosownego raportu lub dashboardu w formatach pdf/png oraz

xls(x).

11. Aplikacja powinna pozwalać na eksportowanie zawartości raportów do plików pdf/xls(x) wraz z informacją

o zastosowanych filtrach.

12. Narzędzie powinno umożliwiać stosowanie formatowania warunkowego wedle definiowanych przez użytkownika

zasad.

13. Aplikacja powinna pozwalać na definiowanie źródeł danych SQL zawierających parametry.

14. Narzędzie powinno umożliwiać przygotowanie - z pomocą kreatora - dodatkowych wyliczanych miar.

15. Narzędzie powinno pozwalać na stosowanie dodatkowych funkcji matematycznych/logicznych/statystycznych i

innych podczas definiowania miar wyliczanych.

16. Aplikacja powinna pozwalać na prowadzenie dyskusji (wysyłania komentarzy) do użytkowników dotyczących

poszczególnych raportów oraz analiz.

17. Platforma powinna przekazywać notyfikacje informując użytkownika o pojawieniu się nowych odpowiedzi w

wątku w którym brał udział.

18. Narzędzie powinno pozwalać na tworzenie interaktywnych kokpitów na których użytkownik może umieszczać

różnego typu wizualizacje (wykresy, tabele, filtry i inne).

19. Narzędzie powinno pozwalać na umieszczenie w strukturze repozytorium odnośników do innego typu dokumentów

zewnętrznych (pdf, xls, strony internetowe).

20. Aplikacja powinna pozwalać na przygotowane kontekstowych raportów, które mogą być wywoływane z poziomu

współpracujących aplikacji.

21. Narzędzie powinno pozwalać na eksport definicji raportu/dashbordu lub struktury repozytorium do pliku.

22. Aplikacja powinna umożliwiać tworzenie filtrów wartościowych dla miar zawężających wyniki analiz do

Strona 123 z 204

zdefiniowanych przez użytkownika wartości/przedziałów wartości.

23. Narzędzie powinno pozwalać na osadzanie w widoku dashboardu odnośników do innych raportów, stron

internetowych oraz wstawianie grafik.

24. Aplikacja powinna umożliwiać w kontekście poszczególnych wizualizacji na tworzenie odnośników do innych

dashboardów lub raportów dostępnych w ramach repozytorium oraz przekazywanie parametrów w oparciu o które

stosowne dane powinny zostać odfiltrowane.

25. Narzędzie powinno pozwalać na tworzenie listy ulubionych miar i wymiarów najczęściej wykorzystywanych przez

użytkownika podczas tworzenia analiz.

26. Aplikacja powinna pozwalać na tworzenie wykresów typu waterfall.

27. Moduł raportowy powinien pozwalać na łatwe przełączenie się pomiędzy widokiem tabelarycznym, a innymi

typami wizualizacji, jak również pozwala na scalenie w obrębie jednego ekranu widoku tabeli oraz

odpowiadającego mu wykresu.

28. Narzędzie powinno posiadać własny silnik przetwarzania danych w pamięci (in-memory) – 10 punktów

29. Narzędzie powinno umożliwiać łączenie danych z różnych źródeł na potrzeby raportowania.

30. Platforma powinna pozwalać na wybór dowolnego dashboardu i ustawienie go jako startowego widoku dostępnego

po zalogowaniu.

31. Powinna istnieć możliwość prezentacji danych z wielu źródeł różnego typu danych na jednym dashboardzie.

32. System powinien umożliwiać użytkownikom zmianę nazw kolumn na raporcie uruchomionym w przeglądarce

internetowej, na dowolnie wybrane przez użytkownika nagłówki i etykiety.

33. System powinien umożliwiać przedstawienie wielu miar na wspólnej osi tego samego wykresu (wykres typu

combo) jak również użycia dwóch niezależnych osi.

34. System zapewnia możliwość opracowania i generowania raportów co najmniej MZ-03, MZ-BFA, F-03

7.1.3.2 Budżetowanie i analiza zarządcza

Lp. Opis wymagania / punktacja

1. Możliwość tworzenia budżetów przychodów i kosztów (np. wg. miejsc powstawania kosztów, prowadzonych

projektów, realizowanych zadań, itp.) – wykorzystujących automatyczną konsolidację i dekompozycję danych.

2. Możliwość definiowania własnej struktury budżetu niezależnej od układu wynikającego z Planu Kont – Budżet

Zarządczy

3. Możliwość tworzenia budżetów na dowolnym poziomie struktury organizacyjnej – tworzenie indywidualnych

budżetów komórkowych, jak i zbiorczego budżetu skonsolidowanego

Strona 124 z 204

4. Automatyczne nanoszenie wykonania (realizacji) budżetów na podstawie dokumentów zaewidencjonowanych w

systemie (zarówno już zaksięgowanych, jak i zaksięgowanych wstępnie).

5. Możliwość wglądu w realizację budżetu dla większej liczby pracowników, z uwzględnieniem ograniczeń dostępu

do danych.

6. Mechanizm parametryzowanych raportów, w tym z elementami graficznymi, przedstawiających stan ich realizacji

i odchylenia (np. pasek zaawansowania)

7. Możliwość tworzenia raportów, zestawień i porównań wersji budżetowych na bazie mechanizmów tabel

przestawnych

8.

Mechanizmy umożliwiające alokację wybranych wartości ekonomicznych do wskazanych komórek

organizacyjnych i kategorii budżetowych. (Np. alokacja kosztów ogólnych na wybrane komórki organizacyjne,

czy Projekty)

9.

Mechanizmy ułatwiające tworzenie kolejnych wersji budżetu w oparciu o automatyczne procesy sterowane

wskazanymi parametrami – np. tworzenie budżetu w oparciu o proporcje wynikające z wykonania roku

poprzedniego

10. Możliwość dodawania komentarzy i notatek do formularzy budżetowych (miejsca do wprowadzania wartości

budżetowych).

11. Możliwość załączania dokumentów zewnętrznych (Word, Excel) do formularzy budżetowych.

12. Możliwość pracy z formularzami budżetowymi w trybie offline lub online WWW

13. Możliwość eksportowania szablonów i zestawień budżetowych do formatów XLS, PDF.

14. Możliwość dokonywania zmian w strukturach budżetowych (dodawanie, przenoszenie komórek organizacyjnych,

dodawanie usuwanie kategorii budżetowych) w dowolnym momencie

15. Tworzenie budżetu na podstawie historycznego budżetu albo danych historycznych.

16. Tworzenie budżetu na podstawie historycznego budżetu albo rzeczywistych i procentowych danych o wzrostach i

zmniejszeniach.

17. Możliwość planowania budżetu

18. Możliwość kontroli stanu realizacji budżetu

19. System umożliwia wprowadzenia planów kont, grup kont księgi głównej dla celów budżetowania lub inne

alternatywnego rozwiązania pozwalające na tworzenie dowolnej struktury budżetu.

20. Wsparcie definiowania i obsługi procesu uzgadniania i zatwierdzania budżetu wewnątrz jednostki

21. Możliwość zastosowania technologii Drill Down i DrillUp (drążenie danych, od ogółu do szczegółu i odwrotnie)

we wszystkich analizach i budżetach.

Strona 125 z 204

22.

Mechanizmy umożliwiające alokację wybranych wartości ekonomicznych do wskazanych komórek

organizacyjnych i kategorii budżetowych. (Np. alokacja kosztów ogólnych na wybrane komórki organizacyjne,

czy umowy)

23.

Dystrybucja dedykowanych formularzy budżetowych do wskazanych użytkowników lub udostępnienie w innych

sposób miejsca do wprowadzania wartości budżetowych do wskazanych użytkowników (np. właścicieli centrów

kosztowych).

24.

Mechanizmy zarządzania rolami i uprawnieniami użytkowników z dokładnością do poszczególnych elementów

struktur budżetowych. Możliwość definiowania indywidualnych praw dostępu do danych oddzielnie w sferze

zapisu i odczytu.

25. Możliwość ręcznego wprowadzania danych o budżecie i jego wykonaniu

26. Możliwość planowania budżetów w układzie "od dołu" i "od góry"

27. Możliwość planowani i rozliczania zakupów wg zdefiniowanych kategorii zakupów (planowanie zakupów

ilościowe i wartościowe)

28. Możliwość kontroli ilościowej albo wartościowej realizacji zakupów

29. Możliwość zasilania budżetów na podstawie wprowadzonych planów Zakupowych

30. Możliwość określenia Dysponenta dla danej kategorii kosztowej z obsługa przypisania prawa do edycji oraz

zatwierdzania budżetu kategorii dla całej instytucji

31. Automatyczne blokowanie środków pod realizacje zakupów (ostrzeżenia kontroli budżetowej).

32. Automatyczne zwalnianie zablokowanych i niewykorzystanych w procesie zakupów środków w budżecie

33. Możliwość tworzenia budżetów w układzie zadaniowym i źródeł finansowania.

34. Planowanie zakupów na przyszły rok na podstawie obrotów magazynowych w danej komórce kosztowej.

35. Możliwość tworzenia analiz wskaźnikowych z automatyczną aktualizacją wartości wskaźników – raportowanie.

36. Możliwość zapisywania stworzonych przez użytkownika raportów i analiz

37. Możliwość tworzenia raportów sięgających bezpośrednio do danych z budżetu i innych modułów źródłowych

38. Możliwość tworzenia zestawień i analiz sięgających do wielu komórek organizacyjnych i pozwalających na

konsolidację danych finansowych

39. Możliwość tworzenia zestawień i analiz obejmujących wiele lat obrotowych

40. Możliwość tworzenia wielowymiarowych analiz w technologii OLAP, ze szczegółowym dostępem do wymiarów

(słowników analitycznych) planu kont i lat obrotowych

41. Możliwość budowania zestawień z dowolnym przedziałem dat, innym jak rok obrotowy (np. od października

Strona 126 z 204

jednego roku do października roku następnego)

42. Możliwość tworzenia raportów i zestawień w oparciu o dane pochodzące z różnych obszarów działalności

przedsiębiorstwa

43. Możliwość wprowadzania do raportów elementów wyliczanych na bazie algorytmów, wymiarów, kluczy

podziałowych (alokacyjnych) wyliczanych dynamicznie oraz statycznie.

44. Możliwość eksportowania raportów do formatu xls.

45. Możliwość tworzenia hierarchicznej struktury centrów kosztów i przychodów oraz innych wymiarów

analitycznych

46. Możliwość różnorodnej graficznej prezentacji danych. (np. wykresy, drzewa dekompozycji, grafy rozkładu

strukturalnego itp.)

47. Możliwość docierania do raportów i analiz poprzez przeglądarkę internetową

48. Możliwość definiowania Kluczowych Wskaźników Wydajności (KPI). Automatyczne wskazywanie ich trendów

przy pomocy symboli graficznych

49. Możliwość tworzenia wskaźnikowych kart wyników (zbiorcze zestawienia KPI) dla dowolnych zdefiniowanych

obszarów działalności przedsiębiorstwa.

50. Możliwość tworzenia Pulpitów Menadżerskich zawierających kluczowe raporty, analizy, karty wyników, grafy

dedykowanych dla użytkowników systemu

51. Mechanizmy zarządzania rolami i uprawnieniami użytkowników

52. Możliwość generowania zestawień kosztów według zadanych kryteriów

53. Możliwość elastycznego definiowania przez użytkownika zestawień dotyczących zbiorczych informacji na temat

rozliczonych kosztów komórki organizacyjnej.

54. Analiza kosztów bezpośrednich w rozbiciu na koszty rodzajowe.

55. Analiza kosztów pośrednich w rozbiciu na koszty rodzajowe.

56. Analiza kosztów całkowitych (bezpośrednich + pośrednich) w rozbiciu na koszty rodzajowe.

57. Przygotowywanie zestawień kosztów w różnych układach, np. według zużycia poszczególnych rodzajów

materiałów.

58. Zestawianie przychodów według grup, miejsc ich powstania itp.

59. Możliwość zdefiniowania wzorców wspomagających rozliczanie.

60. Rozliczanie kosztów ogólnych firmy, np. według zatrudnienia, powierzchni.

Strona 127 z 204

61. Wyliczanie danych do kwartalnej informacji podsumowującej.

62. Bezpośredni wybór kont z planu kont oraz pozycji bilansu i rachunku zysków i strat.

Strona 128 z 204

7.1.3.3 Kalkulacja Kosztów Leczenia

Lp. Opis wymagania

1. System musi umożliwiać dokonywanie wyceny kosztów hospitalizacji pacjenta z uwzględnieniem:

- wykonanych dla pacjenta procedur medycznych

- osobodni pobytu na oddziałach z podziałam na koszty w poszczególnych oddziałach i czasookresach pobytu

- podanych leków

- pobranych materiałów medycznych

- kosztów hotelowych

- kosztów administracyjnych w tym zarządu,

- wyżywienia

- skierowań na usługi zewnętrzne,

- innych,

2. System musi umożliwiać ewidencję różnych cen procedur medycznych w zależności od jednostki wykonującej

procedurę i czasu wykonania.

3. System musi umożliwiać przypisanie różnych cen kosztów pobytu w zależności od jednostki organizacyjnej, typu

łóżka i czasookresu pobytu

4. System musi umożliwiać obliczanie wskaźnika średniej z poniesionego kosztu w ramach danego nośnika kosztów

dla konkretnej wyceny i jednostki organizacyjnej

5. System musi umożliwiać obliczanie wskaźnika średniej z poniesionego kosztu dla konkretnej wyceny i jednostki

chorobowej w danej jednostce

6. System musi umożliwiać podgląd bieżących kosztów hospitalizacji w trakcie pobytu szpitalnego.

7. System musi umożliwiać prezentację kosztów hospitalizacji pacjenta w podziale na pobyty w jednostkach

organizacyjnych i czasookresach, w których pacjent przebywał.

8. System musi udostępniać informację o uzyskanym od płatnika wpływie:

- faktycznym dotyczącym hospitalizacji na podstawie ujęcia produktu jednostkowego na fakturze

- potencjalnym dotyczącym hospitalizacji na podstawie zaewidencjonowanych produktów jednostkowych

9. System musi umożliwiać ustalenie wyniku finansowego pobytu szpitalnego - porównanie kosztów hospitalizacji

pacjenta z przychodami uzyskanymi od płatnika za jego realizację

10. System musi umożliwiać ustalenie wyniku finansowego dotyczącego wizyt w poradniach niezwiązanych z

Strona 129 z 204

hospitalizacją pacjenta - porównanie kosztów pacjenta z przychodami uzyskanymi od płatnika za ich realizację

11. System musi umożliwiać bezpośredni wgląd w dane dotyczące analizowanej hospitalizacji

12. System musi umożliwiać wygenerowanie Rachunku Kosztów Leczenia Pacjenta zawierającego dane o pacjencie,

pobycie szpitalnym, rozpoznaniu, wpływach oraz kosztach

13. System musi umożliwiać wygenerowanie Rachunku Kosztów Leczenia Pacjenta, o którym mowa w punkcie

powyżej zawierającym dodatkową informację o niewycenionych procedurach medycznych wykonanych

pacjentowi

14. System musi umożliwiać zestawienia kosztów i przychodów pobytów szpitalnych i oddziałowych w określonym

przedziale czasowym zawierającego:

- informacje o pacjencie, jednostce, rozpoznaniu zasadniczym, procedurze rozliczeniowej, liczbie osobodni,

koszcie pobytu na oddziale, podanych leków, wykonanych procedur, uzyskanym wpływie,

- opcję filtrowania po dowolnych danych,

- opcję grupowania po dowolnej ilości kolumn,

- automatyczne wyróżnienia (np. poprzez inny kolor) pobytów, których wynik finansowy przekracza określoną

przez użytkownika wartość progową,

- automatyczne wyróżnienia (np. poprzez inny kolor) poszczególne pozycje kosztów składających się na łączny

koszt hospitalizacji pacjenta mające wartość większą niż średnia dla wyświetlonych pobytów,

- przeniesienie danych do arkusza kalkulacyjnego.

15. System musi umożliwiać generowanie zestawienia niewycenionych procedur medycznych wraz z ich ilością,

wykonanych w określonym przedziale czasowym w konkretnej jednostce organizacyjnej

16. System musi umożliwiać wydruk definiowanych zestawień kosztów hospitalizacji w szpitalu / na oddziale z

uwzględnieniem cen badań diagnostycznych określonych w lokalnych cennikach modułów w koszcie planowanym

i rzeczywisty.

17. System musi umożliwiać definiowanie dowolnych raportów i zestawień w tym w formie graficznej dotyczących

danych ewidencjonowanych w module

18. System musi pobierać dane mające wpływ na kalkulację kosztów leczenia oraz wyceny procedur medycznych ze

wszystkich zależnych modułów zintegrowanego system tak z części białej jak i szarej.

7.1.3.4 Kalkulacja Kosztów Procedur Medycznych

Lp. Opis wymagania

34. System musi ewidencjonować informacje o normatywach procedur medycznych z możliwości przypisania

normatywu do kliku procedur wewnętrznych zlecanych w modułach HIS

Strona 130 z 204

35. System musi umożliwiać przypisanie wielu normatywów do jednej procedury wewnętrznej

36. System musi umożliwiać definiowanie normatywów za pomocą dokumentów Kart Normatywnych Procedur

Medycznych – KNPM

37. System musi umożliwiać integrację KNPM z modułem Elektronicznego Obiegu Dokumentów w celu ich

dystrybucji i zatwierdzania

38. System musi umożliwiać przypisanie do KNPM:

- zadań do poszczególnych użytkowników

- dowolnych załączników

- notatek

39. System musi umożliwiać obsługę wielu cenników wykorzystywanych do wyceny normatywów procedur

medycznych

40. System musi umożliwiać integrację Cenników z modułem Elektronicznego Obiegu Dokumentów w celu ich

dystrybucji i zatwierdzania

41. System musi umożliwiać określenie przedziału czasowego w jakim obowiązuje cennik z kontrolą łączności i

rozłączności zdefiniowanych okresów obowiązywania cenników

42. System musi umożliwiać definiowanie kosztu normatywnego procedury medycznej z uwzględnieniem

następujących definiowalnych grup składników:

- koszty leków

- koszty odczynników

- koszty materiałów medycznych,

- koszty aparatury medycznej,

- koszty personelu,

- narzuty kosztów ogólnych

- kosztów normatywnych wcześniej zdefiniowanych

- inne koszty alokowane przy pomocy podzielników kosztów z uwzględnieniem wymiarów finansowych (cech),

43. System musi automatycznie pobierać dane z systemów i modułów, których dotyczą poszczególne grupy

składników w celu w pełni zautomatyzowanej kalkulacji kosztów procedur, także z modułów części szarej (KG,

KiP, ŚT, itd.)

44. System musi umożliwiać definiowanie elementów składowych wyceny procedur medycznych poprzez:

- wykorzystanie katalogu środków farmakologicznych zawartego w module Apteka,

- ręczne definiowanie katalogu materiałów medycznych,

Strona 131 z 204

- wykorzystanie katalogu materiałów medycznych zawartego w module Magazyn,

- ręczne definiowanie katalogu aparatury medycznej,

- wykorzystanie katalogu środków trwałych prowadzonego w module Środki Trwałe

- ręczne definiowanie katalogu grup zawodowych w celu wspólnego liczenia kosztu godziny pracy (np. lekarze

wg specjalizacji),

- wykorzystywanie katalogu grup zawodowych zawartego w modułach Kadry/Płace,

- ręczne definiowanie katalogu zawierającego dowolne inne składniki kosztowe wykorzystywane do wyceny

procedur medycznych, np. jednostki kalkulacyjne, punkty.

45. System musi umożliwiać przypisanie do jednej pozycji w katalogu składowych kilku indeksów z modułów

dziedzinowych z podaniem przy każdym z nich przelicznika do wyceny,

46. System musi umożliwiać obsługę cen jednostkowych w zakresie:

- ręcznego przypisania oraz modyfikacji cen

- automatycznego przypisania cen jednostkowych z modułów dziedzinowych ( Apteka, Magazyn, Ewidencja

Wyposażenia, Moduł Kadrowo-Płacowy itp. )

47. System musi umożliwiać dokonywanie zmian (dodawanie, usuwanie) w katalogach procedur medycznych

poszczególnych ośrodków powstawania kosztów przez autoryzowane osoby.

48. System musi umożliwiać automatyczne pobieranie kosztów bezpośrednich i pośrednich związanych z wykonaniem

procedur medycznych danego ośrodka powstawania kosztów ujętych w układzie podmiotowym, dotyczących

konkretnego okresu rozliczeniowego, które pochodzą z modułu Finansowo-Kosztowego.

49. System musi umożliwiać automatyczne pobieranie ilości wystąpień procedur medycznych w przyjętym okresie

rozliczeniowym dla konkretnego ośrodka powstawania kosztów z modułów Ruchu Chorych.

50. System musi umożliwiać ręczne uzupełnienia lub korygowania ilości wystąpień procedur medycznych w przyjętym

okresie rozliczeniowym.

Wycena kosztów rzeczywistych wykonania procedur medycznych uwzględnieniem:

- wybranego do przeliczenia cennika,

- współczynników podziałowych uzyskanych z wyceny kosztów normatywnych procedur medycznych na

poziomie poszczególnych ośrodków powstawania kosztów,

- liczby wykonanych procedur medycznych w ośrodku kosztów,

- rzeczywistych kosztów bezpośrednich i pośrednich dotyczących wykonania procedur medycznych

zarejestrowanych w systemie Finansowo-Księgowym.

51. System musi umożliwiać rozliczenie kosztów procedur medycznych w przyjętym okresie rozliczeniowym w

konkretnych ośrodkach powstawania kosztów.

52. System musi umożliwiać ustalenie kosztu niewykorzystanych zasobów danego ośrodka powstawania kosztów w

Strona 132 z 204

konkretnym okresie rozliczeniowym poprzez porównanie kosztów normatywnych procedur medycznych z

kosztami rzeczywistymi wykonanych procedur medycznych.

53. System musi umożliwiać wydruk KNPM wraz z informacją o wykorzystanych środkach farmakologicznych,

materiałach medycznych, aparaturze medycznej, procedurach wchodzących w jej skład, grupach zawodowych,

innych składnikach kosztowych wraz z ich kosztem normatywnym.

54. System musi umożliwiać definiowanie dowolnych raportów i zestawień w tym w formie graficznej dotyczących

danych ewidencjonowanych w module

55. System musi umożliwiać eksport do arkusza kalkulacyjnego raportów wykonanych procedur medycznych wraz z

ich ilością, ceną normatywną, wartością normatywną i jednostką wykonującą z podziałem na zdefiniowane rodzaje

kosztów składowych

7.2 INFRASTRUKTURA BAZODANOWA ORAZ SPRZĘTOWA – WYMAGANIA

SZCZEGÓŁOWE

7.2.1 Certyfikat TCO – opis równoważności

W zakresie produkcji:

Potwierdzenie niezależnej organizacji certyfikacyjnej o charakterze i zasięgu międzynarodowym, że

proces produkcji oferowanego sprzętu przebiega w bezpiecznych warunkach, a w szczególności nie

wystawia pracowników na działanie niekorzystnych substancji chemicznych.

Potwierdzenie niezależnej organizacji certyfikacyjnej o charakterze i zasięgu międzynarodowym

Ewelka o przestrzeganiu w stosunku do wszystkich osób zaangażowanych w produkcję praw człowieka

oraz praw dziecka.

Producent musi posiadać certyfikat ISO 14001 na proces produkcji oraz serwisowania sprzętu.

W zakresie bezpieczeństwa użytkownika końcowego:

Certyfikat niezależnej organizacji certyfikacyjnej o charakterze i zasięgu międzynarodowym

potwierdzający, że oferowany sprzęt jest w pełni bezpieczny dla użytkownika końcowego,

a w szczególności zabezpiecza go przed porażeniem prądem elektrycznym.

Potwierdzenie niezależnej organizacji o charakterze i zasięgu międzynarodowym, że oferowany sprzęt

nie emituje szkodliwego promieniowania elektromagnetycznego – dotyczy komputerów stacjonarnych,

komputerów All-In-One oraz ekranów komputerów przenośnych.

W zakresie wydajności oraz kosztów użytkowania sprzętu:

Certyfikat efektywności energetycznej przyznany przez niezależną organizację certyfikacyjną

o charakterze i zasięgu międzynarodowym potwierdzający całkowity koszt użytkowania (TCO - Total

Cost of Ownership) sprzętu – szczególnie w zakresie zużycia energii elektrycznej.

Wykonane przez niezależną organizację certyfikacyjną o charakterze i zasięgu międzynarodowym

badanie emisji hałasu oferowanego sprzętu.

W zakresie obsługi i przedłużenia cyklu przydatności:

Strona 133 z 204

Funkcja umożliwiająca łatwe i bezpowrotne usunięcie wrażliwych danych w przypadku utylizacji,

rozwiązanie sprzętowe, działające również w przypadku uszkodzenia lub braku systemu operacyjnego

na.

Oświadczenie producenta o zapewnieniu dostępności w cyklu życia produktu części zamiennych oraz

eksploatacyjnych.

W zakresie bezpieczeństwa środowiska naturalnego:

Badanie niezależnej organizacji certyfikacyjnej o charakterze i zasięgu międzynarodowym

potwierdzające, że oferowane produkty nie zawierają kadmu, rtęci, ołowiu, sześciowartościowego

chromu oraz innych uznanych za niebezpieczne substancji.

W zakresie recyklingu:

Oświadczenie producenta o prowadzeniu programu utylizacji sprzętu uszkodzonego lub po zakończeniu

cyklu życia sprzętu.

Dokumentacja równoważna do TCO Certifted

Wszystkie normy, certyfikaty i standardy sporządzone przez niezależne, akredytowane jednostki na terenie Polski lub Unii

Europejskiej (jeżeli dotyczy)

Zakres Norma, Standard, Certyfikat Uwagi

Dla

po

dm

iotu

będ

ąceg

o p

rodu

cente

m/f

abry

ki

PN-EN ISO 9001:2015 System Zarządzania Jakością

PN-EN ISO 14001:2015 System Zarządzania Środowiskowego

PN-ISO 45001:2018 System Zarządzania Bezpieczeństwem i Higieną Pracy

PN-EN ISO/IEC 27001:2017 System Zarządzania Bezpieczeństwem Informacji

PN-ISO 37001:2017 System Zarządzania działaniami antykorupcyjnymi

PN-EN ISO 50001:2018

System Zarządzania Energią,

Zarządzanie energią i efektywnością energetyczną w

przedsiębiorstwie

IEEE 1680.1 - 2018

Standard IEEE dla oceny odpowiedzialności

środowiskowej i społecznej komputerów i

wyświetlaczy

W zakresie dla producenta/fabryki – w zakresie

odpowiedzialności społecznej i w zakresie ochrony

środowiska przy projektowaniu sprzętu

komputerowego

Dla

pro

du

ktu

PN-EN ISO 14024:2018 Etykiety i deklaracje środowiskowe -- Etykietowanie

środowiskowe I typu. Zasady i procedury.

PN-EN ISO 7779:2019

Akustyka - Pomiar hałasu rozprzestrzeniającego się w

powietrzu, wytwarzanego przez urządzenia

informatyczne i telekomunikacyjne

Strona 134 z 204

Norma w zakresie akustyki oraz prowadzenia

pomiarów głośności urządzeń

ISO 9296:2017

Akustyka - Deklarowane wartości emisji hałasu

urządzeń informatycznych i telekomunikacyjnych.

Norma dotycząca metodologii określania wartości

uśrednionych poziomów głośności dla partii sprzętów

teleinformatycznych

PN-EN ISO 3741:2011

Akustyka -- Wyznaczanie poziomów mocy

akustycznej i poziomów energii akustycznej źródeł

hałasu na podstawie pomiarów ciśnienia akustycznego

-- Metody dokładne w komorach pogłosowych

Norma w zakresie akustyki – określanie poziomów

mocy dźwięku oraz energii dźwiękowej.

PN-EN ISO 3744:2011

Akustyka -- Wyznaczanie poziomów mocy

akustycznej i poziomów energii akustycznej źródeł

hałasu na podstawie pomiarów ciśnienia akustycznego.

Metody techniczne stosowane w warunkach

zbliżonych do pola swobodnego nad płaszczyzną

odbijającą dźwięk.

Metodyka pomiarowo obliczeniowa w zakresie

wyznaczania poziomu mocy akustycznej i ciśnienia

akustycznego

PN-EN ISO 3745:2012/A1:2017-07

Akustyka -- Wyznaczanie poziomów mocy

akustycznej i poziomów energii akustycznej źródeł

hałasu na podstawie pomiarów ciśnienia akustycznego.

Metody dokładne w komorach bezechowych i w

komorach bezechowych z odbijającą podłogą

PN-EN ISO 11469:2016 wg. ISO 1043 Tworzywa sztuczne -- Identyfikacja rodzaju tworzywa

i znakowanie wyrobów z tworzyw sztucznych

ISO/EIC 28360-1:2018

Informatyka - Sprzęt biurowy - Oznaczanie

wskaźników emisji chemicznej ze sprzętu

elektronicznego - Część 1: Materiały eksploatacyjne

PN-EN IEC 61249-2-45:2018

Materiały na płytki drukowane i inne struktury

wzajemnych połączeń -- Część 2-45: Wzmocnione

materiały podłoża z pokryciem i bez pokrycia -- Płyty

z bezhalogenowej żywicy epoksydowej, o

wzmocnieniu nietkanym/tkanym ze szkła typu E,

foliowane miedzią, o przewodności cieplnej (1,0

W/mK) i określonej palności (pionowa próba

palności), do lutowania bezołowiowego

Norma w zakresie wytwarzania laminatów

drukowanych, bezhalogenowych oraz bez

Strona 135 z 204

I.1.1

System automatycznej digitalizacji dokumentów papierowych wraz z tabletami (oświadczeń woli pacjentów)

w zakresie oświadczeń woli pacjenta, połączonych z dokumentacją pacjenta. System musi kontrolować

kompletność oświadczeń w systemie w zależności od stosowanych procedur medycznych. System musi

umożliwiać składanie oświadczeń przez moduł samoobsługowy online z wykorzystaniem Profilu Zaufanego.

8 GWARANCJA

Oferent w ramach realizacji Przedmiotu Zamówienia udzieli Zamawiającemu gwarancji jakości (dalej zwanej

gwarancją) w następujące okresy:

Dostawa i wdrożenie Szpitalnego Systemu Informatycznego:

Poz. OPZ Opis

Okres gwarancji i

nadzoru autorskiego

(minimalny)

Dostawa i wdrożenie oprogramowania i Sprzętu Komputerowego:

Poz. OPZ Opis

Okres gwarancji

(minimalny)

wykorzystania związków ołowiu

PN-EN IEC 63000:2019

Dokumentacja techniczna do oceny produktów

elektrycznych i elektronicznych w odniesieniu do

ograniczenia substancji niebezpiecznych

Norma w zakresie tworzenia oraz prowadzenia

dokumentacji technicznej do oceny produktów

elektrycznych i elektronicznych w odniesieniu do

ograniczenia substancji niebezpiecznych

Badania zgodności z Dyrektywami EMC i

LVD przez podmiot akredytowany wg PN-EN

ISO/IEC 17025:2018

Badanie kompatybilności elektromagnetycznej

urządzeń elektronicznych i elektrycznych

przeprowadzone przez akredytowane laboratorium

Dyrektywa RoHS w sprawie ograniczenia

stosowania niektórych niebezpiecznych

substancji w sprzęcie elektrycznym i

elektronicznym

Deklaracja w zakresie spełnienia wymogów

dyrektywy ROHS dotycząca ograniczania substancji

niebezpiecznych w produktach elektronicznych

Strona 136 z 204

Bieg terminów gwarancji określonych w ust. 1 będą rozpoczynać się z dniem podpisania Protokołu

Odbioru Końcowego bez uwag przez Zamawiającego.

W okresie gwarancji Oferent będzie zobowiązany do nieodpłatnego usuwania Wad Przedmiotu

Zamówienia rozumianych jako Awaria lub Błąd lub Usterka lub Wadę budowlaną zgodnie z definicjami

jak poniżej:

- Awaria - Kategoria Wady w Oprogramowaniu lub Oprogramowaniu ZSI lub Infrastrukturze

Sprzętowej powodująca brak działania lub niepoprawne działanie Przedmiotu Zamówienia u

Zamawiającego, uniemożliwiające jego użytkowanie. Sytuacja, w której Oprogramowanie w ogóle nie

funkcjonuje lub nie jest możliwe realizowanie istotnych funkcjonalności Komponentów/Produktów

Przedmiotu Zamówienia

- Błąd - Należy przez to rozumieć Wadę Oprogramowania lub Oprogramowania ZSI oznaczającą jego

funkcjonowanie niezgodne z opisem w Dokumentacji oraz OPZ, powodujące błędne zapisy w bazie

danych lub uniemożliwiające działanie mniej istotnej funkcjonalności w Systemie.

- Usterka - Należy przez to rozumieć kategorię Wady w Oprogramowaniu lub Oprogramowaniu ZSI lub

Infrastrukturze Sprzętowej oznaczającą funkcjonowanie niezgodne z opisem Dokumentacji oraz OPZ,

nie wpływającą istotnie na funkcjonowanie dostarczanego rozwiązania u Zamawiającego, utrudniającą

pracę Użytkownikowi Zamawiającego.

- Wada Budowlana - Wszelkie wady wykonanych robót modernizacyjnych powodujące, że są one

niezgodne z Umową lub nie posiadają właściwości, które zgodnie z Umową powinny posiadać.

Przyjęcie zgłoszenia Wady przez Wykonawcę, odbywać się będzie poprzez dostępny on-line System Zgłaszania

i przyjmowania uwag oraz Wad (dalej zwany SZ) przy czym:

System Zgłoszeń dostarczy Oferent (będzie on utrzymywany i administrowany przez Wykonawcę),

wpis zgłoszenia do SZ będzie dokonywał Zamawiający,

za skuteczne przyjęcie zgłoszenia Wady uważa się będzie wprowadzenie przez Zamawiającego wpisu

do SZ zawierającego opis zgłaszanej Wady i termin jej zgłoszenia; w razie trudności z dostępem on-line

do SZ, zgłoszenia Wady mogą odbywać się także telefonicznie pod ustalonym numerem telefonu lub

pisemnie na formularzu przesyłanym na ustalony adres e-mail, opcjonalnie faksem, których numery i

adresy zostaną podane przez Wykonawcę w terminie 15 dni roboczych od dnia podpisania Umowy

wraz ze wzorem formularza zgłoszenia Wady.

W przypadku, w którym wykonanie Umowy związane będzie z modernizacją lub rozbudową istniejącego

oprogramowania, gwarancja obejmuje całość oprogramowania modernizowanego lub rozbudowywanego.

Gwarancja musi zapewniać wymianę uszkodzonego sprzętu, kabli i elementów oraz zapewniać dostęp do

aktualizacji oprogramowania, bez wiedzy i wsparcia technicznego producenta.

W ramach gwarancji Oferent będzie świadczył następujące usługi:

Usuwanie Wad w dostarczonym Przedmiocie Zamówienia w przypadku stwierdzenia przez Zamawiającego

Wady w jego działaniu, w terminach określonych poniżej:

Dostawa i wdrożenie oprogramowania i Sprzętu Komputerowego:

a) Sprzęt komputerowy:

Dostawa i wdrożenie oprogramowania i Sprzętu Komputerowego:

a) Sprzęt komputerowy:

KWALIFIKACJA

ZGŁOSZENIA

WADY

OKRES

DOSTĘPNOŚCI

OFERENTA

ROZWIĄZANIE

ZASTĘPCZE

CZAS REAKCJI

OFERENTA

CZAS

NAPRAWY

- serwerowy, tj. serwery aplikacyjne, serwery bazodanowe, macierz:

Strona 137 z 204

KWALIFIKACJA

ZGŁOSZENIA

WADY

OKRES

DOSTĘPNOŚCI

OFERENTA

ROZWIĄZANIE

ZASTĘPCZE

CZAS REAKCJI

OFERENTA

CZAS

NAPRAWY

AWARIA

24/7/365

niezwłocznie, nie

później niż 24

godziny od czasu

przyjęcia zgłoszenia

niezwłocznie, nie

później niż 24

godziny od czasu

przyjęcia zgłoszenia

niezwłocznie,

nie później

niż 72 godziny

od czasu

przyjęcia

zgłoszenia

USTERKA nie dotyczy

niezwłocznie nie

później niż 5 dni

roboczych od dnia

przyjęcia zgłoszenia

niezwłocznie

nie później niż

14 dni od dnia

przyjęcia

zgłoszenia

- pozostały sprzęt komputerowy:

AWARIA W dni robocze

pomiędzy 8.00 a

16.00. Zgłoszenie

przesłane po 16.00,

traktowane jest jak

zgłoszenie przyjęte

w następnym dniu

roboczym o 8.00

niezwłocznie, nie

później niż 24

godziny od czasu

przyjęcia zgłoszenia

niezwłocznie, nie

później niż 24

godziny od czasu

przyjęcia zgłoszenia

niezwłocznie,

nie później

niż 96 godzin

od czasu

przyjęcia

zgłoszenia

USTERKA nie dotyczy

niezwłocznie nie

później niż 5 dni

roboczych od dnia

przyjęcia zgłoszenia

niezwłocznie

nie później niż

14 dni od dnia

przyjęcia

zgłoszenia

b) oprogramowanie systemowe i narzędziowe:

KWALIFIKACJA

ZGŁOSZENIA

WADY

OKRES

DOSTĘPNOŚCI

OFERENTA

ROZWIĄZANIE

ZASTĘPCZE

CZAS

REAKCJI

OFERENTA

CZAS

NAPRAWY

AWARIA

W dni robocze

pomiędzy 8.00 a

16.00. Zgłoszenie

przesłane po 16.00,

traktowane jest jak

zgłoszenie przyjęte

niezwłocznie, nie

później niż 24 godzin

od czasu przyjęcia

zgłoszenia

niezwłocznie, nie

później niż 24

godzin od czasu

przyjęcia

zgłoszenia

niezwłocznie,

nie później

niż 96 godzin

od czasu

przyjęcia

zgłoszenia

Strona 138 z 204

KWALIFIKACJA

ZGŁOSZENIA

WADY

OKRES

DOSTĘPNOŚCI

OFERENTA

ROZWIĄZANIE

ZASTĘPCZE

CZAS

REAKCJI

OFERENTA

CZAS

NAPRAWY

BŁĄD

w następnym dniu

roboczym o 8.00

nie dotyczy

niezwłocznie nie

później niż 2 dni

robocze od dnia

przyjęcia

zgłoszenia

niezwłocznie

nie później niż

14 dni od dnia

przyjęcia

zgłoszenia

USTERKA nie dotyczy

niezwłocznie nie

później niż 5 dni

roboczych od

dnia przyjęcia

zgłoszenia

niezwłocznie

nie później niż

30 dni od dnia

przyjęcia

zgłoszenia

Dostawa i wdrożenie Szpitalnego Systemu Informatycznego:

a) Szpitalny System Informatyczny

KWALIFIKACJA

ZGŁOSZENIA

WADY

OKRES

DOSTĘPNOŚCI

OFERENTA

ROZWIĄZANIE

ZASTĘPCZE

CZAS

REAKCJI

OFERENTA

CZAS

NAPRAWY

AWARIA

W dni robocze

pomiędzy 8.00 a

16.00. Zgłoszenie

przesłane po 16.00,

traktowane jest jak

zgłoszenie przyjęte

w następnym dniu

roboczym o 8.00

niezwłocznie, nie

później niż 12 godzin

od czasu przyjęcia

zgłoszenia

niezwłocznie, nie

później niż 24

godzin od czasu

przyjęcia

zgłoszenia

niezwłocznie,

nie później

niż 72 godziny

od czasu

przyjęcia

zgłoszenia

BŁĄD nie dotyczy

niezwłocznie nie

później niż 2 dni

robocze od dnia

przyjęcia

zgłoszenia

niezwłocznie

nie później niż 5

dni roboczych

od dnia

przyjęcia

zgłoszenia

USTERKA nie dotyczy

niezwłocznie nie

później niż 5 dni

roboczych od

dnia przyjęcia

zgłoszenia

niezwłocznie

nie później niż

10 dni

roboczych od

dnia przyjęcia

zgłoszenia

Strona 139 z 204

dopuszcza się zmianę kwalifikacji zgłoszenia Wady, po uprzedniej zgodzie Zamawiającego. Do czasu

potwierdzenia zmiany kwalifikacji, uznaje się za obowiązującą kwalifikację pierwotną,

czasy naprawy mogą być inne niż wskazane w powyższych tabelach, jeżeli Zamawiający zaakceptuje

zmianę kwalifikacji zgłoszenia, o której mowa powyżej

w przypadku braku możliwości usunięcia Wady lub przedstawienia rozwiązania zastępczego zdalnie,

Oferent zobowiązany jest do świadczenia gwarancji bezpośrednio w lokalizacji Zamawiającego,

usunięcie Wady Oprogramowania, nastąpi poprzez przekazanie poprawki lub nowej wersji. Każda nowa

poprawka lub nowa wersja musi posiadać unikalny numer.

Oferent w okresie trwania gwarancji, do 5 dnia każdego miesiąca, przedstawi Zamawiającemu raport

zawierający co najmniej: numer zgłoszenia, kwalifikację zgłoszenia, godzinę i datę zgłoszenia, temat

zgłoszenia, status zgłoszenia, godzinę i datę usunięcia Wady, czas naprawy,

wykonywania Serwisu - Oprogramowania na poniższych zasadach:

wykonywania modyfikacji bez wezwania lub na pisemne zgłoszenie Zamawiającego w celu dostosowania

wszystkich elementów Oprogramowania do obowiązujących przepisów prawnych,

przekazania Zamawiającemu informacji o nowych wersjach Oprogramowania drogą elektroniczną na

wskazany adres e-mail Zamawiającego,

udostępniania nowych wersji Oprogramowania poprzez ustaloną witrynę internetową lub serwer ftp, w

szczególności związanych z wejściem w życie nowych przepisów prawa lub zawierających nowe

funkcjonalności; w przypadku w którym udostępnianie następować będzie w związku ze zmianą przepisów

prawa, Oferent zobowiązany będzie do jej dokonania na nie mniej niż 14 dni przed dniem wejścia w życie

tych przepisów. W uzasadnionych przypadkach, Zamawiający dopuści aby Oferent udostępnił odpowiednie

zmiany w terminach umożliwiających Zamawiającemu wywiązanie się ze zmienionych przepisów prawa.

każda nowa wersja musi posiadać unikalny numer;

wraz z nową wersją Oferent zobowiązany jest do przekazania nowej wersji Dokumentacji Powykonawczej

wraz z procedurą instalacji oraz informacją

o parametryzacji i konfiguracji.

świadczenia usług w postaci konsultacji, porad, wsparcia technicznego w zakresie wdrożenia oraz

użytkowania Oprogramowania, przy czym:

- usługi będą świadczone w dni robocze w godzinach od 8.00 do 16.00 w języku polskim,

- tryb zgłaszania: telefonicznie, e-mail, faxem lub poprzez System Zgłoszeń,

- konsultacje i porady będą udzielane na bieżąco podczas rozmowy telefonicznej lub

w postaci elektronicznej, jeżeli wynika to z przedmiotu usługi, jednak nie później niż w ciągu

3 dni roboczych od skierowania zapytania. Jeżeli nie jest możliwe wykonanie usługi w ciągu

3 dni roboczych, Oferent uzgodni z Zamawiającym inny termin konsultacji lub porady.

Pozostałe ustalenia:

a. System Zgłoszeń, który zostanie udostępniony przez Wykonawcę, ma dodatkowo pozwalać na

prowadzenie rejestru kontaktów z Zamawiającym obejmującego

w szczególności wykonane czynności gwarancyjne, ewidencję wszystkich zgłoszeń

gwarancyjnych, opis zmian w konfiguracji Oprogramowania; prowadzenie rejestru zgłoszeń jest

obowiązkiem Oferenta.

b. Zamawiający przekaże Oferenta, zgodnie ze stanem swojej wiedzy, informacje

o aktach prawa wewnętrznego obowiązującego w Podmiocie leczniczym, które mają zastosowanie

w realizacji niniejszej Umowy.

Zamawiający ustala procedurę zdalnego dostępu Oferenta do Oprogramowania:

1) Oferent drogą elektroniczną poprzez e-mail, prześle Zamawiającemu wniosek

o uzyskanie zdalnego dostępu do Oprogramowania, wskazując co najmniej:

a) imię i nazwisko pracownika Oferenta, któremu zostanie przyznany dostęp,

b) nazwa i adres IP zasobu (bazy danych/oprogramowania), który zostanie udostępniony,

c) usługi sieciowe, które zostaną udostępnione,

d) okres czasu, na który będzie aktywowany dostęp,

e) numer zgłoszenia gwarancyjnego,

f) przyczyna złożenia wniosku,

Strona 140 z 204

g) opis czynności, które zostaną wykonane,

h) imię i nazwisko pracownika Oferenta uprawnionego do złożenia wniosku.

2) osoba wyznaczona przez Zamawiającego zaopiniuje wniosek i w formie elektronicznej poprzez e-mail

odpowie, podając informację o zgodzie lub jej braku.

3) po zakończeniu prac Oferent ma obowiązek przesłać Zamawiającemu raport

z wykonanych prac z wykorzystaniem zdalnego dostępu, podając czas ich trwania

i zakres.

4) każdy zdalny dostęp do Oprogramowania musi być przez Wykonawcę odnotowany

w Systemie Zgłoszeń,

5) dostęp do zasobów Zamawiającego musi być zgodny z obowiązującą u niego polityką bezpieczeństwa.

Zamawiający udostępni procedury bezpieczeństwa Oferenta, którego oferta zostanie wybrana jako

najkorzystniejsza, po podpisaniu umowy.

W przypadku dostarczenia nowej lub zmodyfikowanej wersji Oprogramowania wymagającego aktualizacji

lub wymiany Oprogramowania dostarczonego w ramach niniejszej Umowy, Oferent w ramach gwarancji

ma obowiązek wymiany lub aktualizacji także tego Oprogramowania.

Okres gwarancji dla Oprogramowania ZSI jest równy okresowi nadzoru autorskiego,

w ramach którego Oferent zobowiązuje się do:

wykonywania modyfikacji bez wezwania lub na pisemne zgłoszenie Zamawiającego w celu

dostosowania wszystkich elementów Oprogramowania ZSI do obowiązujących przepisów prawnych,

przekazania Zamawiającemu informacji o nowych wersjach oprogramowania drogą elektroniczną na

wskazany adres e-mail Zamawiającego,

udostępniania nowych wersji oprogramowania poprzez ustaloną witrynę internetową,

w szczególności związanych z wejściem w życie nowych przepisów prawa lub zawierających nowe

funkcjonalności, w szczególności związane z rozliczeniami z NFZ; w przypadku w którym

udostępnianie następować będzie w związku ze zmianą przepisów prawa, Oferent zobowiązany

będzie do udostępnienia nowej wersji oprogramowania na nie mniej niż 14 dni przed dniem wejścia w

życie tych przepisów; udostępniania nowych wersji oprogramowania poprzez ustaloną witrynę

internetową, w szczególności związanych z wejściem w życie nowych przepisów prawa lub

zawierających nowe funkcjonalności, w szczególności związane z rozliczeniami

z NFZ; w przypadku w którym udostępnianie następować będzie w związku ze zmianą przepisów

prawa, Oferent zobowiązany będzie do jej dokonania na nie mniej niż 14 dni przed dniem wejścia w

życie tych przepisów, a w przypadku, gdy przepisy te będą wchodziły w życie w terminie krótszym

niż 14 dni od daty ich publikacji,

w terminie nie później jak 14 dni od ich publikacji;

wysłania na adres korespondencyjny Zamawiającego nośnika CD/DVD zawierającego nową wersję

oprogramowania, na pisemne żądanie wniesione przez Zamawiającego - każda nowa wersja musi

posiadać unikalny numer;

wraz z nową wersją oprogramowania Oferent zobowiązany jest do przekazania nowej wersji

Dokumentacji wraz z procedurą instalacji oprogramowania oraz informacją

o parametryzacji i konfiguracji.

świadczenia usług w postaci konsultacji, porad, wsparcia technicznego w zakresie wdrożenia oraz

użytkowania oprogramowania ZSI w wymiarze do 2000 roboczogodzin, przy czym:

1) usługi będą świadczone w dni robocze w godzinach od 8.00 do 16.00 w języku polskim, w

siedzibie Zamawiającego lub za uzgodnieniem Stron, jako prace świadczone zdalnie

2) tryb zgłaszania: telefonicznie, e-mail, faxem lub poprzez Elektroniczny System Zgłoszeń,

konsultacje i porady będą udzielane na bieżąco podczas rozmowy telefonicznej lub w postaci

elektronicznej, jednak nie później niż w ciągu 3 dni roboczych od skierowania zapytania. Jeżeli

nie jest możliwe wykonanie usługi w ciągu 3 dni roboczych, Oferent uzgodni z Zamawiającym

inny termin konsultacji lub porady, jeżeli Zamawiający wyrazi na to zgodę.

Strona 141 z 204

Uwaga:

W przypadku zapisu terminu jako:

Dzień Roboczy należy rozumieć każdy dzień od poniedziałku do piątku z wyłączeniem dni ustawowo wolnych

od pracy.

Godziny Robocze należy rozumieć godziny od 8.00 do 16.00 w każdym Dniu Roboczym.

W innych przypadkach należy rozumieć jako dzień kalendarzowy.

9 SPOSÓB I FORMA KOMUNIKACJI W POSTĘPOWANIU ORAZ

MINIMALNE WYMAGANIA SPRZĘTOWE

1. Postępowanie prowadzone jest w języku polskim na elektronicznej Platformie Zakupowej (dalej:

„Platforma”) pod

adresem: https://szpitalpraski.ezamawiajacy.pl/pn/szpitalpraski/demand/notice/public/current/list?

USER_MENU_HOVER=currentNoticeList i pod nazwą „dostawa i wdrożenie systemu

informatycznego e-Usługi wraz z modernizacją lub wymianą zintegrowanego systemu

zarządzania (HIS + ERP), systemów powiązanych i sprzętu”,

2. Pod adresem, o którym mowa w ust. 1, dostępna jest dokumentacja przedmiotowego

postępowania.

3. Wykonawca przystępując do postępowania o udzielenie zamówienia publicznego, tj. rejestrując

się lub w przypadku posiadania konta w Platformie, logując się, akceptuje Regulamin

zamieszczony na stronie internetowej: https://oneplace.marketplanet.pl/regulamin_ezamawiajacy

a także uznaje go za wiążący.

4. W zakładce „Regulacje i procedury procesu zakupowego” zamieszczona jest „Instrukcja dla

Wykonawcy”, która zawiera pełną instrukcję korzystania z Platformy.

5. Pod pojęciem Platforma należy rozumieć narzędzie umożliwiające realizację procesu związanego

z udzielaniem zamówień publicznych w formie elektronicznej, służące

w szczególności do przekazywania ofert, oświadczeń, w tym Jednolitego Europejskiego

Dokumentu Zamówienia (dalej także jako „JEDZ”).

6. Korzystanie z Platformy jest bezpłatne.

7. W zakładce „Pierwotne Dokumenty Zamówienia” dostępna jest dokumentacja postępowania.

Pobieranie dokumentów następuje po kliknięciu na wybrany dokument i wciśnięciu polecenia:

„Pobierz”.

8. Zamawiający informuje, iż udostępnia na stronie internetowej pod adresem:

https://szpitalpraski.ezamawiajacy.pl/pn/szpitalpraski/demand/notice/public/current/list?USER_

MENU_HOVER=currentNoticeList dokumentację postępowania,

w szczególności specyfikację istotnych warunków zamówienia od dnia opublikowania ogłoszenia

o zamówieniu w Dzienniku Urzędowym Unii Europejskiej udostępnionym na stronach portalu

internetowego Dziennika Urzędowego Unii Europejskiej do upływu terminu składania ofert.

9. W zakładce „Lista Przetargów i Dialogów Technicznych”, dalej „Aktualne” Wykonawca wybiera

niniejsze postępowanie oraz korzystając z polecenia „Przystąp do Postępowania” przechodzi

odpowiednio do formularza rejestracyjnego - w przypadku, kiedy Wykonawca nie posiada konta

na ww. platformie lub panelu logowania użytkowania do systemu.

10. Po wypełnieniu formularza rejestracyjnego Wykonawca otrzymuje e-maila informującego,

że może dokonać pierwszego logowania do Platformy.

Strona 142 z 204

11. Zgłoszenie do postępowania wymaga zalogowania Wykonawcy do systemu. Po wprowadzeniu

danych użytkownika, tj. adresu e-mail oraz hasła zgłoszenie jest automatycznie akceptowane

przez system.

12. Rejestracja Wykonawcy trwa maksymalnie do 2 dni roboczych. W związku z tym Zamawiający

zaleca Wykonawcom uwzględnienie czasu niezbędnego na ww. rejestrację w procesie złożenia

Oferty w postaci elektronicznej.

13. Wykonawca wraz z potwierdzeniem złożenia wniosku rejestracyjnego otrzyma informację o

możliwości przyspieszenia procedury założenia konta.

14. Wykonawca składa ofertę w formie zaszyfrowanej, dlatego też oferty nie są widoczne do

momentu odszyfrowania ofert przez Zamawiającego, który następuje po terminie otwarcia.

Ważne – oferta zapisana na Platformie nie oznacza, że została ona złożona. Zapisanie oferty daje

użytkownikowi czas, na wprowadzenie ewentualnych poprawek, uzupełnień, dołączenie

dodatkowych załączników. Wybór ikony ZŁÓŻ OFERTĘ / WNIOSEK oznacza złożenie oferty /

wniosku – zgodnie z przepisami ustawy Pzp.

15. Komunikacja między Zamawiającym, a Wykonawcami, w szczególności zawiadomienia oraz

informacje, przekazywane są w formie elektronicznej za pośrednictwem Platformy w zakładce

„Pytania i odpowiedzi”.

16. Zamawiający, zgodnie z §4 Rozporządzenia Prezesa Rady Ministrów w sprawie użycia środków

komunikacji elektronicznej w postepowaniu o udzielenie zamówienia publicznego oraz

udostępnienia i przechowywania dokumentów elektronicznych (Dz. U.z 2018 r. poz. 1991),

zwanego dalej „Rozporządzeniem” określa dopuszczalny format kwalifikowanego podpisu

elektronicznego jako:

1) dokumenty w formacie „pdf’ zaleca się podpisywać formatem PAdES;

2) dopuszcza się podpisywanie dokumentów w formacie innym niż „pdf” wtedy będzie

wymagany oddzielny plik z podpisem. W związku z tym Wykonawca będzie zobowiązany

załączyć oddzielny plik z podpisem.

17. Zamawiający, zgodnie z §3 ust. 3 ww. Rozporządzenia, określa niezbędne wymagania sprzętowo-

aplikacyjne, umożliwiające pracę na „Platformie e-Zamawiający”:

1. stały dostęp do sieci Internet o gwarantowanej przepustowości nie mniejszej niż 512 kb/s;

2. komputer klasy PC lub MAC o następującej konfiguracji: pamięć min. 2 GB RAM, procesor

Intel IV 2 GHz, jeden z systemów operacyjnych: MS Windows 7, Mac Os x 10.4, Linux lub

ich nowsze wersje;

3. zainstalowana dowolna przeglądarka internetowa obsługująca TLS 1.2, najlepiej

w najnowszej wersji, w przypadku Internet Explorer minimalnie wersja 10.0;

4. włączona obsługa JavaScripy;

5. zainstalowany program Acrobat Reader, lub inny obsługujący pliki w formaciepdf.

18. Zamawiający, zgodnie z §3 ust. 3 ww. Rozporządzenia, określa dopuszczalne formaty

przesyłanych danych, tj. plików o wielkości do 100 MB w formatach: pdf., exel, doc., zip.

19. Zamawiający, zgodnie z §3 ust. 3 ww. Rozporządzenia, określa informacje na temat kodowania i

czasu odbioru danych:

Strona 143 z 204

1) plik załączony przez Wykonawcę na Platformie i zapisany, widoczny jest na Platformie, jako

zaszyfrowany – format kodowania UTF8. Możliwość otworzenia pliku dostępna jest dopiero

po odszyfrowaniu przez Zamawiającego, które następuje po terminie otwarcia ofert;

2) oznaczenie czasu odbioru danych przez platformę stanowi datę oraz dokładny czas (hh:mm:ss)

generowany wg. czasu lokalnego serwera synchronizowanego z odpowiednim źródłem czasu –

zegarem głównego instytutu miar.

10 WARUNKI UDZIAŁU W POSTĘPOWANIU ORAZ OPIS SPOSÓB

DOKONYWANIA OCENY SPEŁNIANIA TYCH WARUNKÓW

1. O udzielenie zamówienia mogą ubiegać się Wykonawcy, którzy:

1) nie podlegają wykluczeniu na podstawie art. 24 ust. 1 pkt. 12-23 ustawy Pzp;

2) nie podlegają wykluczeniu na podstawie art. 24 ust. 5 pkt. 1 ustawy Pzp, tj.

- zgodnie z wyżej wskazanym przepisem z postępowania wyklucza się Wykonawcę w stosunku do

którego otwarto likwidację, w zatwierdzonym przez sąd układzie

w postępowaniu restrukturyzacyjnym jest przewidziane zaspokojenie wierzycieli przez likwidację

jego majątku lub sąd zarządził likwidację jego majątku w trybie art. 332 ust. 1 ustawy z dnia 15

maja 2015 r. prawo restrukturyzacyjne (Dz. U. z 2017 r. poz. 1508 oraz z 2018 r. poz.

149, 398, 1544 i 1629) lub którego upadłość ogłoszono,

z wyjątkiem Wykonawcy, który po ogłoszeniu upadłości zawarł układ zatwierdzony

prawomocnym postanowieniem sądu, jeżeli układ nie przewiduje zaspokojenia wierzycieli przez

likwidację majątku upadłego, chyba że sąd zarządził likwidację jego majątku w trybie art. 366 ust.

1 ustawy z dnia 28 lutego 2003 r. - prawo upadłościowe (Dz.U. z 2017 r. poz. 2344 i 2491 oraz z

2018 r. poz. 398, 685, 1544 i 1629);

3) spełniają warunki udziału w postępowaniu dotyczące:

a) kompetencji lub uprawnień do prowadzenia określonej działalności zawodowej, o ile

wynika to z odrębnych przepisów,

Zamawiający nie stawia szczególnych wymagań w zakresie spełniania tego warunku.

b) sytuacji ekonomicznej lub finansowej

Zamawiający uzna powyższy warunek za spełniony, jeżeli Wykonawca wykaże, iż:

- posiadają środki finansowe lub zdolność kredytową, w okresie nie wcześniejszym

niż 1 miesiąc przed upływem terminu składania ofert na kwotę co najmniej

1 500 000,00 złotych (jeden milion pięćset tysięcy złotych),

c) zdolności technicznej lub zawodowej;

- w zakresie posiadania doświadczenia:

Zamawiający wymaga na potwierdzenie spełnienia tego warunku, aby Wykonawca w

okresie ostatnich trzech lat przed upływem terminu składania ofert, a jeżeli okres prowadzenia

działalności jest krótszy – w tym okresie, wykonał, minimum 2 (dwie)główne dostawy

odpowiadające swoim rodzajem dostawie stanowiącej przedmiot zamówienia,tj.:obejmujące

Strona 144 z 204

swym zakresem odpowiednio dostawę, instalację, konfigurację i wdrożenie zintegrowanych

gotowych systemów typu HIS, jednego producenta, do którego dostęp jest oparty o

przeglądarkę www dla podmiotów leczniczych funkcjonujących w systemie ochrony zdrowia

według przepisów właściwych dla danego kraju z minimalną liczbą łóżek 150, wraz z

podaniem ich wartości, przedmiotu zamówienia, dat wykonania, podmiotów, na rzecz których

zostały wykonane oraz załączeniem dowodów, określających czy dostawa została wykonana

lub jest wykonywana należycie, przy czym dowodami, o których mowa, są referencje bądź

inne dokumenty wystawione przez podmiot, na rzecz którego były wykonywane, przy czym:

za gotowy zintegrowany system typu HIS jednego producenta do którego dostęp jest oparty

o przeglądarkę www Zamawiający uzna system, który składa się z co najmniej

z następujących obszarów funkcjonalnych:

a) obsługa ruchu chorych – izba przyjęć,

b) obsługa ruchu chorych – oddział,

c) obsługa przychodni – rejestracja,

d) obsługa przychodni – gabinet lekarski,

e) obsługa dokumentacji medycznej,

f) obsługa statystyki medycznej,

g) obsługa apteki,

h) obsługa apteczek oddziałowych,

i) obsługa rozliczeń z NFZ (lub równoważnemu mu innego podmiotu pełniącego funkcję

płatnika w systemie opieki zdrowotnej) - lecznictwo otwarte i zamknięte.

Wartość każdej z dostaw, o których mowa powyżej może być niższa niż 1 500 000,00

PLN brutto,

- w zakresie posiadania potencjału osobowego:

Zamawiający wymaga na potwierdzenie spełnienia tego warunku, aby Wykonawca wykazał dysponowanie odpowiednim potencjałem osobowym, gwarantującym należytą realizację przedmiotu zamówienia. Wykonawca musi dowieść, iż dysponuje lub będzie dysponował osobami zdolnymi do wykonania zamówienia:

Kierownik Projektu (minimum 1 osoba):

posiadający kwalifikacje potwierdzoneważnymi certyfikatami: „PRINCE2” lub IPMA lub

równoważny; który w ciągu ostatnich 3 lat zrealizował, pełniąc funkcję kierownika projektu,

co najmniej 2 projekty z budżetem równym lub powyżej

1 500 000,00 PLN brutto;

Architekt (minimum 1 osoba):

posiadający doświadczenie w zakresie projektowania(tworzenia) architektury

wielowarstwowych systemów informatycznych, o wysokiej wydajności i niezawodności,

który w ciągu ostatnich 3 lat, brał udział w co najmniej 2 projektach obejmujących swym

zakresem budowę architekturysystemów informatycznych dedykowanych dla jednostek opieki

Strona 145 z 204

zdrowotnej i był odpowiedzialny za zaprojektowanie architektury IT systemu; wartość co

najmniej jednego z tych projektów była równa lub większa niż 1 500 000,00 PLN brutto;

UWAGA!

- poprzez „certyfikat równoważny” Zamawiający rozumie, że Wykonawca przedstawi

certyfikat, który jest analogiczny, co do zakresu z przykładowymi certyfikatami

wskazanymi z nazwy dla danej roli, co jest rozumiane jako analogiczna dziedzina

merytoryczna wynikająca z roli, której dotyczy certyfikat (np. kompetencje związane

z zarządzaniem projektami), analogiczny stopień poziomu kompetencji (np. podstawowy,

zaawansowany, ekspert), analogiczny poziom doświadczenia zawodowego wymagany do

otrzymania danego certyfikatu (np. konieczność wykazania się uczestnictwem w

określonej liczbie projektów danej roli lub liczba lat pracy w danej roli, etc.);

- potwierdzony jest egzaminem (dotyczy tylko tych ról, których przykładowe certyfikaty

muszą być potwierdzone egzaminem),

- przypadku korzystania z potencjału osobowego firm trzecich, należy złożyć

odpowiednie oświadczenia firm zobowiązujące do oddania osób na czas wykonywania

zamówienia z oznaczeniem zamówienia i roli wykonywanej w zamówieniu,

- zamówienie będzie realizowane w języku polskim, w związku z czym Wykonawca musi

zapewnić możliwość swobodnego komunikowania się personelu realizującego przedmiot

zamówienia z Zamawiającym w języku polskim oraz sporządzania dokumentacji w języku

polskim.

2. W przypadku Wykonawców wspólnie ubiegających się o udzielenie zamówienia, warunki o

których mowa w ust.1 pkt. 3 mogą oni spełniać łącznie, natomiast wykazanie braku podstaw

wykluczenia, o których mowa w ust. 1 pkt. 1, 2 musi wykazać odrębnie każdy

z Wykonawców.

3. Zamawiający, zgodnie z art.24aa ustawy Pzp, najpierw dokona oceny ofert, a następnie

zbada, czy Wykonawca, którego oferta została oceniona jako najkorzystniejsza, nie

podlega wykluczeniu oraz spełnia warunki udziału w postępowaniu.

11 WYKAZ OŚWIADCZEŃ I DOKUMENTÓW, JAKIE MAJĄ DOSTARCZYĆ

WYKONAWCY W CELU POTWIERDZENIA SPEŁNIANIA WARUNKÓW

UDZIAŁU W POSTĘPOWANIU

1. W celu potwierdzenia wstępnego spełniania warunków udziału w postępowaniu oraz

w celu wykazania braku podstaw do wykluczenia Wykonawca składa formularz jednolitego

europejskiego dokumentu zamówienia, zwanego dalej „JEDZ”.

2. Oświadczenie, o którym mowa w ust.1 Wykonawca składa w formie (JEDZ), sporządzonego

zgodnie z wzorem standardowego formularza określonego w rozporządzeniu wykonawczym

Komisji Europejskiej KE (UE) 2016/7 z dnia 5 stycznia 2016 r., wydanym na podstawie art. 59

ust. 2 dyrektywy 2014/24/UE oraz art. 80 ust. 3 dyrektywy 2014/25/UE, którego wzór stanowi

Załącznik nr 6 do SIWZ.

Strona 146 z 204

3. Jeżeli Wykonawca wykazując spełnianie warunków udziału w postępowaniu, polega na

zdolnościach innych podmiotów, na zasadach określonych powyżej, jest zobowiązany

przedstawić – dla każdego z podmiotów, których to dotyczy odrębny formularz JEDZ.

4. Wykonawca, który zamierza powierzyć wykonanie części zamówienia podwykonawcom, w celu

wykazania braku istnienia wobec nich podstaw wykluczenia z udziału

w postępowaniu składa odrębne formularze JEDZ dotyczące tych podwykonawców.

5. W przypadku wspólnego ubiegania się o zamówienie przez wykonawców, jednolity dokument

składa każdy z wykonawców wspólnie ubiegających się o zamówienie. Dokumenty te

potwierdzają spełnianie warunków udziału w postępowaniu oraz brak podstaw wykluczenia w

zakresie, w którym każdy z wykonawców wykazuje spełnianie warunków udziału w

postępowaniu oraz brak podstaw wykluczenia.

Wykonawcy wspólnie ubiegający się o udzielenie zamówienia, ustanawiają pełnomocnika do

reprezentowania ich w postępowaniu albo do reprezentowania ich

w postępowaniu i zawarcia umowy.

6. Zamawiający przed udzieleniem zamówienia, wezwie Wykonawcę, którego oferta została

najwyżej oceniona, do złożenia w wyznaczonym, nie krótszym niż 10 dni, terminie aktualnych na

dzień złożenia następujących oświadczeń lub dokumentów:

1) w celu potwierdzenia spełniania przez Wykonawcę warunków udziału

w postępowaniu:

- informację banku lub spółdzielczej kasy oszczędnościowo-kredytowej potwierdzającej

wysokość posiadanych środków finansowych lub zdolność kredytową Wykonawcy, w okresie

nie wcześniejszym niż 1 miesiąc przed upływem terminu składania ofert na kwotę co najmniej

1 500 000 złotych (jeden milion pięćset tysięcy złotych),

- wykaz dostaw wykonanych (zgodnie z Załącznikiem nr 7 do SIWZ), a w przypadku

świadczeń okresowych lub ciągłych również wykonywanych, w okresie ostatnich 3 lat przed

upływem terminu składania ofert, a jeżeli okres prowadzenia działalności jest krótszy – w tym

okresie, wraz z podaniem ich wartości, przedmiotu, dat wykonania i podmiotów, na rzecz

których usługi zostały wykonane, oraz załączeniem dowodów określających czy te usługi

zostały wykonane lub są wykonywane należycie, przy czym dowodami, o których mowa, są

referencje bądź inne dokumenty wystawione przez podmiot, na rzecz którego usługi były

wykonywane, a w przypadku świadczeń okresowych lub ciągłych są wykonywane, a jeżeli z

uzasadnionej przyczyny o obiektywnym charakterze wykonawca nie jest w stanie uzyskać

tych dokumentów – oświadczenie wykonawcy; w przypadku świadczeń okresowych lub

ciągłych nadal wykonywanych referencje bądź inne dokumenty potwierdzające ich należyte

wykonywanie powinny być wydane nie wcześniej niż 3 miesiące przed upływem terminu

składania ofert, zawierający co najmniej 2 zamówienia obejmujące dostawę, instalację,

konfigurację i wdrożenie zintegrowanych gotowych systemów typu HIS, jednego producenta,

do którego dostęp jest oparty o przeglądarkę www, dla podmiotów leczniczych

funkcjonujących w systemie ochrony zdrowia według przepisów właściwych dla danego kraju

z minimalną liczbą łóżek 150, o wartości nie mniejszej niż 1.500.000,00 złotych brutto każde.

Strona 147 z 204

Wykonawca wykaże wartości samych usług określonych w warunku udziału w postępowaniu,

bez wartości pozostałych elementów kontraktu, np. dostaw sprzętu. Wykonawca wskaże

dokładną nazwę zrealizowanej usługi, która pozwoli na jednoznaczną identyfikację usługi wraz z

podaniem ich wartości, przedmiotu, dat wykonania i podmiotów, na rzecz których dostawy lub

usługi zostały wykonane.

- wykaz osób (zgodnie z Załącznikiem nr 7 do SIWZ), które zostaną skierowane przez

Wykonawcę do realizacji przedmiotu zamówienia, w szczególności odpowiedzialnych za

świadczenie usług, kontrolę jakości, wraz z informacjami na temat ich kwalifikacji

zawodowych, uprawnień, doświadczenia i wykształcenia niezbędnego do realizacji

zamówienia publicznego, a także zakresu wykonywanych przez te osoby czynności oraz

informacją o podstawie do dysponowania tymi osobami.

2) w celu potwierdzenia braku podstaw wykluczenia wykonawcy z udziału

w postępowaniu Zamawiający żąda następujących dokumentów:

-informacji z Krajowego Rejestru Karnego w zakresie określonym w art. 24 ust. 1 pkt. 13, 14 i 21

ustawy Pzp, wystawionej nie wcześniej niż 6 miesięcy przed upływem terminu składania

ofert;

- odpisu z właściwego rejestru lub z centralnej ewidencji i informacji o działalności

gospodarczej, jeżeli odrębne przepisy wymagają wpisu do rejestru lub ewidencji,

w zakresie art. 24 ust. 5 pkt. 1 ustawy Pzp;

- oświadczenia Wykonawcy o braku wydania wobec niego prawomocnego wyroku sądu lub

ostatecznej decyzji administracyjnej o zaleganiu z uiszczaniem podatków, opłat lub składek

na ubezpieczenia społeczne lub zdrowotne albo – w przypadku wydania takiego wyroku lub

decyzji – dokumentów potwierdzających dokonanie płatności tych należności wraz z

ewentualnymi odsetkami lub grzywnami lub zawarcie wiążącego porozumienia w sprawie spłat

tych należności, w zakresie art. 24 ust. 1 pkt. 15 ustawy Pzp (wzór oświadczenia stanowi

Załącznik nr 10 do SIWZ);

- oświadczenia Wykonawcy o braku orzeczenia wobec niego tytułem środka

zapobiegawczego zakazu ubiegania się o zamówienia publiczne, w zakresie art. 24 ust. 1 pkt.

22 ustawy Pzp (wzór oświadczenia stanowi Załącznik nr 9 do SIWZ).

Jednocześnie Zamawiający informuje, że uwzględniając dyspozycję art. 26 ust. 6 ustawy

Pzp, w celu potwierdzenia braku podstaw wykluczenia z postępowania w zakresie wskazanym w

pkt. 2 tiret 2, samodzielnie pobierze i skorzysta z dokumentów z dokumentów znajdujących się

w bezpłatnych i ogólnodostępnych bazach danych.

7. Wykonawca w terminie 3 dni od dnia zamieszczenia na stronie internetowej informacji,

o której mowa w art. 86 ust. 5 ustawy Pzp, przekaże zamawiającemu oświadczenie

o przynależności lub braku przynależności do tej samej grupy kapitałowej, o której mowa w art. 24

ust. 1 pkt. 23 ustawy. Wraz ze złożeniem oświadczenia, Wykonawca może przedstawić dowody, że

powiązania z innym wykonawcą nie prowadzą do zakłócenia konkurencji w postępowaniu o

udzielenie zamówienia, zgodnie z wzorem stanowiącym Załącznik nr 8 do SIWZ.

Strona 148 z 204

8. Inne dokumenty:

1) Zamawiający żąda załączenia do oferty Pełnomocnictwa (oryginał dokumentu lub kopia

dokumentu poświadczona przez osobę do tej czynności umocowanej „za zgodność

z oryginałem”) z którego będzie wynikać zakres umocowania do podpisania oferty, o ile prawo

do reprezentowania Wykonawcy nie wynika z innych dokumentów, złożonych wraz z ofertą.

W przypadku Wykonawców wspólnie ubiegających się o udzielenie zamówienia, do oferty

należy dołączyć pełnomocnictwo podpisane przez uprawnionych przedstawicieli pozostałych

Wykonawców, upoważniające jednego z Wykonawców do reprezentowania pozostałych.

9. Zamawiający żąda od Wykonawcy, który polega na zdolnościach lub sytuacji innych podmiotów

na zasadach określonych w art. 22a ustawy Pzp, przedstawienia w odniesieniu do tych

podmiotów dokumenty, o których mowa w pkt. 6 pkt. 2 SIWZ.

10. Zamawiający żąda od Wykonawcy przedstawienia dokumentów wymienionych w ust. 6 pkt. 2,

dotyczących podwykonawcy, któremu zamierza powierzyć wykonanie części zamówienia, a

który nie jest podmiotem, na którego zdolnościach lub sytuacji wykonawca polega na zasadach

określonych w art. 22a ustawy Pzp.

11. Jeżeli Wykonawca ma siedzibę lub miejsce zamieszkania poza terytorium Rzeczpospolitej

Polskiej, zamiast dokumentów, o których mowa w ust. 6 pkt. 2 tiret 1 składa informację z

odpowiedniego rejestru albo, w przypadku braku takiego rejestru inny równoważny dokument

wydany przez właściwy organ sądowy lub administracyjny kraju, w którym wykonawca ma

siedzibę lub miejsce zamieszkania lub miejsce zamieszkania ma osoba, której dotyczy informacja

albo dokument, w zakresie określonym w art. 24 ust. 1 pkt. 13, 14 i 21 ustawy Pzp.

12. Jeżeli Wykonawca ma siedzibę lub miejsce zamieszkania poza terytorium Rzeczpospolitej

Polskiej, zamiast dokumentu, o którym mowa w pkt. 6 pkt. 2 tiret 2 składa dokument lub

dokumenty wystawione w kraju, w którym ma siedzibę lub miejsce zamieszkania potwierdzające,

że nie otwarto jego likwidacji ani nie ogłoszono upadłości.

13. Dokumenty, o których mowa w ust. 11i 12 powinny być wystawione nie wcześniej niż 6 miesięcy

przed upływem terminu składania ofert.

14. Jeżeli w kraju, w którym Wykonawca ma siedzibę lub miejsce zamieszkania lub kraju,

w którym miejsce zamieszkania mają osoby, których dokument dotyczy, nie wydaje się

dokumentów, o których mowa w ust. 10 - 11, zastępuje się je dokumentem zawierającym

odpowiednio oświadczenie Wykonawcy, ze wskazaniem osoby albo osób uprawnionych do jego

reprezentacji, lub oświadczeniem osoby, której dokument miał dotyczyć złożone przed

notariuszem łub przed organem sądowym, administracyjnym albo organem samorządu

zawodowego lub gospodarczego, właściwym ze względu na siedzibę lub miejsce zamieszkania

wykonawcy lub miejsce zamieszkania tej osoby. Postanowienia ust. 13 stosuje się

15. Wykonawca mający siedzibę na terytorium Rzeczpospolitej Polskiej, w odniesieniu do osoby,

mającej miejsce zamieszkania poza terytorium Rzeczpospolitej Polskiej, której dotyczy

dokument, wskazany w pkt. 6 pkt. 2 tiret 1 składa dokument, o którym mowa w pkt. 10. w

zakresie określonym w art. 24 ust. 1 pkt. 14 i 21 ustawy Pzp. Jeżeli w kraju, w którym miejsce

zamieszkania ma osoba, której, dokument miał dotyczyć, nie wydaje się takich dokumentów -

Strona 149 z 204

zastępuje się je dokumentem zawierającym oświadczenie tej osoby złożonym przed notariuszem

lub przed organem sądowym, administracyjnym albo organem samorządu zawodowego lub

gospodarczego właściwym ze względu na miejsce zamieszkania tej osoby. Postanowienia ust. 13

stosuje się.

16. Forma dokumentów: oświadczenia woli składane są w oryginale, w postaci dokumentu

elektronicznego uwierzytelnionego kwalifikowanym podpisem elektronicznym. Dokumenty inne

niż oświadczenia woli składane są w oryginale lub kopii dokumentu w postaci dokumentu

elektronicznego, uwierzytelnionego kwalifikowanym podpisem elektronicznym

17. Poświadczenia za zgodność z oryginałem dokonuje odpowiednio Wykonawca, podmiot, na

którego zdolnościach lub sytuacji polega Wykonawca, Wykonawcy wspólnie ubiegający się o

udzielenie zamówienia publicznego albo podwykonawca, w zakresie dokumentów lub

oświadczeń, które każdego z nich dotyczą. Wszelkie oświadczenia woli, muszą być

obligatoryjnie podpisane przez osoby do dokonania rzeczonej czynności uprawnionych oraz

składane w oryginale. Dokumenty lub oświadczenia sporządzone w języku obcym muszą być

składane wraz z tłumaczeniem na język polski.

18. Poświadczenia za zgodność z oryginałem elektronicznej kopii dokumentu lub oświadczenia

następuje przy użyciu kwalifikowanego podpisu elektronicznego.

19. Uwaga: Jeżeli Wykonawca powołuje się na oświadczenia lub dokumenty, będące

w posiadaniu Zamawiającego, potwierdzające okoliczności, o których mowa w art. 25 ust. 1 pkt.

1 i 3 Ustawy, zaleca się wskazanie w ofercie informacji czy Zamawiający jest

w posiadaniu oświadczeń lub dokumentów dotyczących Wykonawcy (z podaniem numeru i

nazwy postępowania Zamawiającego, w którym powyższe dokumenty zostały złożone) lub

wskazanie nazwy ogólnodostępnych baz danych, w szczególności rejestrów publicznych w

rozumieniu ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów

realizujących zadania publiczne (ze wskazaniem adresu internetowego, wydającego urzędu lub

organu, z dokładnymi danymi referencyjnymi dokumentacji).

20. Instrukcja wypełniania Jednolitego dokumentu zamówienia (JEDZ):JEDZ należy złożyć w formie

wskazanej w ust.19.

21. W postępowaniu JEDZ należy złożyć w postaci elektronicznej, opatrzonej kwalifikowanym

podpisem elektronicznym. Oświadczenia podmiotów składających ofertę wspólnie oraz

podmiotów udostępniających potencjał składane na formularzu JEDZ powinny mieć formę

dokumentu elektronicznego, podpisanego kwalifikowanym podpisem elektronicznym przez

każdego z nich w zakresie w jakim potwierdzają okoliczności, o których mowa w treści art. 22

ust. 1 ustawy Pzp. Analogiczny wymóg dotyczy JEDZ składanego przez podwykonawcę, na

podstawie art. 25a ust. 5 pkt 1 ustawy Pzp.

22. Środkiem komunikacji elektronicznej, służącym złożeniu JEDZ przez Wykonawcę, jest

Platforma.

Strona 150 z 204

UWAGA

Załącznik nr 5 do SIWZ w formacie xml, po zaimportowaniu do narzędzia dostępnego pod

adresem: https://ec.europa.eu/growth/tools-databases/espd/filter?lang=pl umożliwi wypełnienie

JEDZ za pomocą powyższego narzędzia i w zakresie wskazanym przez Zamawiającego. W celu

wypełnienia JEDZ należy wykonać kolejno następujące czynności: pobrać plik w formacie xml

stanowiący Załącznik nr 5 do SIWZ; wskazać, że podmiot korzystający z narzędzia jest

Wykonawcą; zaznaczyć czynność za importowania ESPD; załadować pobrany plik, wybrać

państwo Wykonawcy i przejść dalej, do wypełniania JEDZ.

Wykonawca wypełnia JEDZ tworząc dokument elektroniczny. Może korzystać z serwisu

eESPD (https://ec.europa.eu/growth/tools-databases/espd) lub innych dostępnych narzędzi lub

oprogramowania, które umożliwiają wypełnienie JEDZ i utworzenie dokumentu elektronicznego,

lub za pośrednictwem elektronicznej Platformy pod adresem:

https://szpitalpraski.ezamawiajacy.pl/servlet/HomeServlet/.

WYMAGANIA DOTYCZĄCE FORMY DOKUMENTÓW

23. Zamawiający może żądać przedstawienia oryginału lub notarialnie poświadczonej kopii

dokumentów innych niż oświadczenia, wyłącznie wtedy, gdy złożona przez Wykonawcę kopia

dokumentu jest nieczytelna lub budzi wątpliwości co do jej prawdziwości.

24. Wszelkie oświadczenia woli, muszą być obligatoryjnie podpisane przez osoby do dokonania

rzeczonej czynności uprawnionych oraz składane w oryginale.

25. Dokumenty lub oświadczenia sporządzone w języku obcym są składane wraz z tłumaczeniem

na język polski.

12 RODO

1) Informacje dotyczące RODO:

Zgodnie z art. 13 ust. 1 i 2 rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z

dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem

danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy

95/46/WE (ogólne rozporządzenie o ochronie danych) (Dz. Urz. UE L 119 z 04.05.2016, str. 1),

dalej „RODO”, informuję, że:

1. administratorem Pani/Pana danych osobowych jest Szpital Praski p.w. Przemienienia Pańskiego

Sp. z o.o. w Warszawie, Al. Solidarności 67, 03-401 Warszawa, wpisaną do Rejestru

Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m.st. Warszawy, XIIIU wydział

Gospodarczy Krajowego Rejestru Sądowego pod numerem 0000468274, kapitał zakładowy

17.005.000 zł, NIP: 1132866688, REGON: 012298823;

2. kontakt z inspektorem ochrony danych osobowych w Szpitalu Praskim wyłącznie drogą pisemną:

IOD@szpitalpraski.pl;

3. Pani/Pana dane osobowe przetwarzane będą na podstawie art. 6 ust. 1 lit. c RODO

w celu związanym z postępowaniem o udzielenie zamówienia publicznego

nr ZP/11/HIS+ERP/2020/UE, prowadzonym w trybie przetargu nieograniczonego;

4. odbiorcami Pani/Pana danych osobowych będą osoby lub podmioty, którym udostępniona

zostanie dokumentacja postępowania w oparciu o art. 8 oraz art. 96 ust. 3 ustawy Pzp;

Strona 151 z 204

5. Pani/Pana dane osobowe będą przechowywane, zgodnie z art. 97 ust. 1 ustawy Pzp, przez okres 4

lat od dnia zakończenia postępowania o udzielenie zamówienia, a jeżeli czas trwania umowy

przekracza 4 lata, okres przechowywania obejmuje cały czas trwania umowy;

6. obowiązek podania przez Panią/Pana danych osobowych bezpośrednio Pani/Pana dotyczących

jest wymogiem ustawowym określonym w przepisach ustawy Pzp, związanym z udziałem w

postępowaniu o udzielenie zamówienia publicznego; konsekwencje niepodania określonych

danych wynikają z ustawy Pzp;

7. w odniesieniu do Pani/Pana danych osobowych decyzje nie będą podejmowane

w sposób zautomatyzowany, stosowanie do art. 22 RODO;

8. posiada Pani/Pan:

- na podstawie art. 15 RODO prawo dostępu do danych osobowych Pani/Pana

dotyczących;

- na podstawie art. 16 RODO prawo do sprostowania Pani/Pana danych osobowych*;

- na podstawie art. 18 RODO prawo żądania od administratora ograniczenia przetwarzania

danych osobowych z zastrzeżeniem przypadków, o których mowa w art. 18 ust. 2 RODO

**;

- prawo do wniesienia skargi do Prezesa Urzędu Ochrony Danych Osobowych, gdy uzna

Pani/Pan, że przetwarzanie danych osobowych Pani/Pana dotyczących narusza przepisy

RODO;

9. nie przysługuje Pani/Panu:

- w związku z art. 17 ust. 3 lit. b, d lub e RODO prawo do usunięcia danych osobowych;

- prawo do przenoszenia danych osobowych, o którym mowa w art. 20 RODO;

na podstawie art. 21 RODO prawo sprzeciwu, wobec przetwarzania danych

osobowych, gdyż podstawą prawną przetwarzania Pani/Pana danych osobowych jest

art. 6 ust. 1 lit. c RODO.

*Wyjaśnienie: skorzystanie z prawa do sprostowania nie może skutkować zmianą wyniku

postępowania

o udzielenie zamówienia publicznego ani zmianą postanowień umowy w zakresie niezgodnym z

ustawą Pzp oraz nie może naruszać integralności protokołu oraz jego załączników.

**Wyjaśnienie: prawo do ograniczenia przetwarzania nie ma zastosowania w odniesieniu

doprzechowywania, w celu zapewnienia korzystania ze środków ochrony prawnej lub w celu ochrony

praw innej osoby fizycznej lub prawnej, lub z uwagi na ważne względy interesu publicznego Unii

Europejskiej lub państwa członkowskiego

13 INFORMACJE O SPOSOBIE UDZIELANIA WYJAŚNIEŃ

DOTYCZĄCYCH TEŚCI SIWZ

1 Wykonawca może zwrócić się do Zamawiającego o wyjaśnienie treści SIWZ. Wniosek należy

przesłać za pośrednictwem Platformy Zakupowej w zakładce "ZADAJ PYTANIE":

Strona 152 z 204

a) w celu zadania pytania Zamawiającemu, Wykonawca wybiera ikonę ZADAJ PYTANIE.

Powoduje to otwarcie okna, w którym należy uzupełnić wszystkie dane Wykonawcy, temat

i treść/przedmiot pytania,

b) po wypełnieniu wskazanych pól wraz z wymaganym kodem weryfikującym z obrazka

Wykonawca wybiera ikonę POTWIERDŹ,

c) wykonawca uzyskuje potwierdzenie wysłania pytania poprzez komunikat systemowy

"pytanie wysłane".

2 Wykonawca może zwrócić się do Zamawiającego z wnioskiem o wyjaśnienie treści SIWZ.

Procedura wyjaśniania lub zmiany treści SIWZ określona została w art. 38 ustawy Pzp.

Zamawiający udzieli Wykonawcy wyjaśnień niezwłocznie, jednak nie później niż w terminie

określonym w art. 38 ust. 1 ustawy Pzp, przekazując treść pytań i wyjaśnień Wykonawcom,

którym przekazał SIWZ, bez ujawniania źródeł zapytania, pod warunkiem, że wniosek o

wyjaśnienie treści SIWZ wpłynął do Zamawiającego nie później niż do końca dnia, w którym

upływa połowa wyznaczonego terminu składania ofert. Jeżeli wniosek o wyjaśnienie treści

SIWZ wpłynie po upływie terminu, o którym mowa w zdaniu poprzednim, lub dotyczy już

udzielonych wyjaśnień, Zamawiający może udzielić wyjaśnień albo pozostawić wniosek bez

rozpoznania.

3 W przypadku rozbieżności pomiędzy treścią SIWZ a treścią udzielonych wyjaśnień

jako obowiązującą należy przyjąć treść pisma zawierającego późniejsze oświadczenie

Zamawiającego.

14 WYMAGANIA DOTYCZĄCE WADIUM

Zamawiający wymaga wniesienia wadium, na cały okres związania ofertą, w wysokości:

20 000,00 zł (Słownie: dwadzieścia tysięcy złotych)

Wadium może być wniesione w następujących formach:

w pieniądzu na rachunek Zamawiającego w Banku Gospodarstwa Krajowego I Oddział w

Warszawie, nr konta: 96 1130 1017 0020 0760 6720 0002;

poręczeniach bankowych lub poręczeniach spółdzielczej kasy oszczędnościowo-kredytowej, z

tym, że poręczenie kasy jest zawsze poręczeniem pieniężnym,

gwarancjach bankowych,

gwarancjach ubezpieczeniowych,

poręczeniach udzielanych przez podmioty, o których mowa w art. 6b ust. 5 pkt.2 ustawy z

dnia 9 listopada 2000 r. o utworzeniu Polskiej Agencji Rozwoju Przedsiębiorczości (Dz. U. z

2018 r. poz. 110, 650, 1000 i 1669).

Zamawiający zwraca wadium na zasadach określonych w art. 46 ustawy Pzp.

Wykonawca wskaże w Formularzu oferty nr rachunku bankowego, na który należy zwróci

wadium wniesione w pieniądzu.

Strona 153 z 204

15 TERMIN ZWIĄZANIA OFERTĄ

1. Wykonawca jest związany ofertą przez okres 60 dni. Bieg terminu związania ofertą rozpoczyna

się wraz z upływem terminu składania ofert.

2. Wniesienie odwołania zawiesza bieg terminu związania ofertą do czasu ostatecznego

rozstrzygnięcia odwołania.

3. Przedłużenie terminu związania ofertą jest dopuszczalne tylko z jednoczesnym przedłużeniem

ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony

okres związania ofertą. Jeżeli przedłużenie terminu związania ofertą dokonywane jest po wyborze

oferty najkorzystniejszej, obowiązek wniesienia nowego wadium lub jego przedłużenia dotyczy

jedynie Wykonawcy, którego oferta została wybrana jako najkorzystniejsza.

16 OPIS SPOSOBU PRZYGOTOWANIA OFERT I OPIS SPOSOBU

OBLICZENIA CENY

Opis sposobu przygotowania ofert.

1. Wykonawca może złożyć tylko jedną ofertę. Wykonawca składa ofertę za pośrednictwem

Platformy.

2. Oferta powinna być sporządzona w języku polskim, z zachowaniem formy elektronicznej pod

rygorem nieważności i podpisana kwalifikowanym podpisem elektronicznym.

3. Oferta musi obejmować całość zamówienia, a jeżeli Zamawiający dopuścił składanie ofert

częściowych oferta musi obejmować całość danej części zamówienia.

4. Ofertę stanowi wypełniony Formularz Oferty, sporządzony zgodnie z wzorem stanowiącym

Załącznik nr 4oraz 4a do niniejszej SIWZ oraz pozostałe dokumenty wymienione, które należy

złożyć wraz z ofertą.

5. Zgodnie z art. 36b ust 1 ustawy Pzp, Zamawiający żąda wskazania przez Wykonawcę

w Formularzu Oferty części zamówienia, których wykonanie zamierza powierzyć

podwykonawcom i podania przez Wykonawcę firm (nazw) podwykonawców.

6. W przypadku udziału w wykonaniu zamówienia podwykonawców Wykonawca umieszcza w

ofercie odpowiednią informację. Zamawiający nie ogranicza udziału podwykonawców w

wykonaniu zamówienia pod warunkiem posiadania przez nich odpowiednich uprawnień do

realizacji powierzonej im części zamówienia. Kwestie udziału podwykonawców w tym

rozliczeń z Wykonawcą zawarte zostały w Istotnych postanowieniach umowy.

7. Wraz z ofertą powinny być złożone następujące dokumenty:

oświadczenia wstępnie potwierdzające brak podstaw do wykluczenia oraz spełnianie

warunków udziału w postępowaniu w formie Jednolitego Europejskiego Dokumentu

Zamówienia,

pełnomocnictwo do reprezentowania wszystkich Wykonawców wspólnie ubiegających się o

udzielenie zamówienia, ewentualnie umowa o współdziałaniu,

z której będzie wynikać przedmiotowe pełnomocnictwo. Pełnomocnik może być

ustanowiony do reprezentowania Wykonawców w postępowaniu albo reprezentowania w

postępowaniu i zawarcia umowy,

Strona 154 z 204

pełnomocnictwo do podpisania oferty - o ile uprawnienie do podpisania oferty

nie wynika z innych dokumentów złożonych wraz z ofertą,

dowód wniesienia wadium. W przypadku, gdy wymagane wadium wnoszone jest

w innej formie niż pieniądz, Wykonawca powinien złożyć wraz z ofertą oryginał gwarancji

lub poręczenia podpisany przez wystawcę (gwaranta) kwalifikowanym podpisem

elektronicznym.

oferta, oświadczenia i dokumenty, dla których Zamawiający określił wzory (formularze)

powinny być sporządzone zgodnie z tymi wzorami, co do treści oraz opisu kolumn i wierszy,

zaleca się, aby oferta zawierała spis treści oraz numerację stron,

jeżeli w ofercie znajdują się informacje stanowiące tajemnicę przedsiębiorstwa

w rozumieniu przepisów o zwalczaniu nieuczciwej konkurencji, Wykonawca obowiązany

jest jednoznacznie zastrzec, które spośród zawartych w ofercie informacji stanowią

tajemnicę przedsiębiorstwa oraz umieścić je w osobnym pliku z oznaczonym typem

dokumentu jako „TAJEMNICA PRZEDSIĘBIORSTWA”,

Zamawiający uwzględni zastrzeżenie, o którym mowa powyżej pod warunkiem, że

Wykonawca:

a. wskaże w sposób jednoznaczny informacje podlegające tajemnicy przedsiębiorstwa;

b. do oferty załączy nieobjęte zastrzeżeniem uzasadnienie zastrzeżenia poprzez wskazanie

przyczyn faktycznych wraz ze wskazaniem spełnienia podstaw normatywnych

uprawniających do dokonania zastrzeżenia;

c. do oferty załączy streszczenie lub opis zastrzeżonych informacji

i dokumentów, który Zamawiający będzie mógł udostępniać osobom trzecim.

w przypadku braku wskazania w sposób jednoznaczny, które informacje podlegają ochronie,

jako tajemnica przedsiębiorstwa lub braku uzasadnienia zastrzeżenia poprzez wskazanie

przyczyn faktycznych wraz ze wskazaniem spełnienia podstaw normatywnych

uprawniających do dokonania zastrzeżenia, Zamawiający może nie uznać prawidłowości

dokonanego zastrzeżenia tajemnicy przedsiębiorstwa bez obowiązku żądania dodatkowych

wyjaśnień od Wykonawcy. W takim przypadku Zamawiający zwolniony będzie od wszelkiej

odpowiedzialności za jakiekolwiek ewentualne szkody powstałe w związku z ujawnieniem

zastrzeżonych informacji osobom trzecim. Zamawiający poinformuje Wykonawcę o braku

uznania prawidłowości dokonanego przez Wykonawcę zastrzeżenia tajemnicy

przedsiębiorstwa.

przed podjęciem decyzji o braku uznania prawidłowości dokonanego przez Wykonawcę

zastrzeżenia tajemnicy przedsiębiorstwa, Zamawiający może zażądać od Wykonawcy

dodatkowych wyjaśnień.

8. Wykonawca nie może skutecznie zastrzec, iż podlegającą ochronie tajemnicę przedsiębiorstwa

stanowią informacje podawane do wiadomości podczas otwarcia ofert, to jest w szczególności

informacje dotyczące ceny, terminu wykonania zamówienia, okresu gwarancji i warunków

płatności zawartych w ofercie.

Strona 155 z 204

9. Opis sposobu obliczenia ceny:

1) cena oferty powinna być obliczona zgodnie z Formularzem oferty, stanowiącym Załącznik nr 4do

SIWZ,

2) cenę oferty (zawierającą wszystkie jej składniki) należy podać w PLN, z dokładnością do

dwóch miejsc po przecinku, zaokrąglając zgodnie z zasadami rachunkowymi,

3) W łącznej cenie oferty brutto należy uwzględnić wszystkie koszty, opłaty konieczne do

wykonania przedmiotu umowy oraz ewentualne upusty i rabaty,

4) nie przewiduje się udzielania zaliczek,

5) ceny podane przez Wykonawców ustalone są na cały okres obowiązywania umowy,

do porównania ofert będzie zastosowana wartość brutto części

17. MIEJSCE, TERMIN SKŁADANIA ORAZ OTWARCIA OFERT

1. Ofertę należy złożyć za pomocą platformy zakupowej

https://szpitalpraski.ezamawiajacy.pl/pn/szpitalpraski/demand/notice/public/current/list?USER

_MENU_HOVER=currentNoticeList:

do dnia 22.04.2020 roku, do godz. 10:00

2. Otwarcie ofert nastąpi w siedzibie Zamawiającego, za pośrednictwem platformy zakupowej

https://szpitalpraski.ezamawiajacy.pl/servlet/HomeServlet/

w dniu 22.04.2020 roku, do godz. 10:30

3. Wszystkie oferty otrzymane przez Zamawiającego po terminie podanym powyżej zostaną

zwrócone bez otwierania po upływie terminu na wniesienie środków ochrony prawnej.

4. Otwarcie ofert na platformie zakupowej dokonywane jest poprzez odszyfrowanie i otwarcie

ofert, które jest jednoznaczne z ich upublicznieniem na tejże platformie.

5. Upublicznienie należy rozumieć poprzez dostęp do otwartych na Platformie przez

Zamawiającego ofert, bez konieczności faktycznego/fizycznego udziału Wykonawców

w siedzibie Zamawiającego. Zamawiający nie wyklucza możliwości udziału Wykonawców i

innych zainteresowanych osób na otwarciu ofert w siedzibie Zamawiającego (budynek D, pokój

D/120, Dział Zamówień Publicznych).

6. Informację z otwarcia ofert, o której jest mowa w art. 86 ust. 5 ustawy Pzp Zamawiający

udostępni na Platformie zakupowej oraz na stronie Zamawiającego.

18 KRYTERIA, KTÓRYMI ZAMAWIAJĄCY BĘDZIE SIĘ KIEROWAŁ

PRZY WYBORZE OFERT

Strona 156 z 204

1. Zamawiający dokona oceny, a następnie wyboru najkorzystniejszej oferty spośród ofert

spełniających wymagania ustanowione treścią SIWZ, z analogiczną oceną kryteriów oceny ofert i

przypisanych im wag:

Kryteria i zasady oceny ofert:

1) Kryterium: Cena brutto zamówienia - waga 60%

2) Kryterium: Funkcjonalność systemu - waga 30%

3) Kryterium: Termin gwarancji - waga 10%

Ad. I. Kryterium: Cena brutto zamówienia będzie wyliczane na podstawie niżej przedstawionego

wzoru oraz warunków:

C of. n.

Cn = ----------------------- x 60

C of. b.

gdzie:

Cn – liczba otrzymanych punktów za kryterium cena

C of. n. – cena oferty najniższej

C of. b. – cena oferty badanej

Ad. II. Kryterium: Funkcjonalność dodatkowa systemu będzie wyliczane na podstawie niżej

przedstawionego wzoru oraz warunków:

F of. b.

Fn = ----------------------- x 30

F of. n.

gdzie:

Fn – liczba otrzymanych punktów za kryterium funkcjonalności dodatkowej systemu,

F of. n. – największa oferowanaliczba deklaracji twierdzącychdla funkcjonalności dodatkowej

systemu („TAK” / „JEST”),

F of. b. – największa oferowana liczba deklaracji twierdzących dla funkcjonalności dodatkowej

systemu(„TAK” / „JEST”) oferty badanej.

Strona 157 z 204

W ramach tego kryterium ocena oferowanego systemu dokonana zostanie przez

Zamawiającego na podstawie oświadczenia Wykonawcy na formularzu znajdującym się w Załączniku

nr 4a do SIWZ „Tabela funkcjonalności dodatkowych”, stanowiącego integralną część Formularza

Oferty.

Instrukcja wypełnienia Załącznika 4a do SIWZ:

W kolumnie „Spełnia TAK/NIE” należy wpisać słowo „Tak” w przypadku spełnienia określonego

w wierszu wymogu funkcjonalnego (w całości)

W kolumnie „Spełnia TAK/NIE” należy wpisać słowo „Nie” w przypadku gdy nie spełnienia

określonego w wierszu wymogu funkcjonalności (w całości)

Brak wpisu, nieczytelny wpis lub odpowiedź negatywna oznacza w kolumnie „Spełnia TAK/NIE”

uznawany jest jako brak potwierdzenia danej funkcjonalności dodatkowej i skutkuje nie uznaniem tej

pozycji w sumowaniu odpowiedzi twierdzących, których suma będzie podstawiana do wzoru celem

wyliczenia uzyskanych punktów dla pozacenowego kryterium oceny ofert.Pola zaznaczone znakiem

„X” nie podlegają wypełnieniu.

Ad. III. Kryterium: Okres gwarancji:będzie wyliczane na podstawie niżej przedstawionego wzoru

oraz warunków:

G of. b.

Gn = ----------------------- x 10

G of. n.

gdzie:

Gn – liczba otrzymanych punktów za kryterium okresu gwarancji

G of. n. – najdłuższy oferowany termin gwarancji (liczba pełnych miesięcy)

G of. b. – termin gwarancji oferty badanej (liczba pełnych miesięcy)

Uwaga!

Pod powyższym należy rozumieć udzielenie gwarancji na zrealizowany przedmiot

zamówienia na okres od 36 miesięcy (minimalny okres gwarancyjny) do 60 miesięcy (maksymalny

okres gwarancyjny).

W sytuacji, gdy Wykonawca nie wskaże w ofercie okresu gwarancji, oferta taka zostanie

uznana za ofertę z minimalnym wymaganym okresem gwarancji (czyli 36 miesięcy). W sytuacji, gdy

Wykonawca wskaże w ofercie okres gwarancji krótszy niż 36 miesięcy, Zamawiający odrzuci ofertę

jako niezgodną z SIWZ.

Termin gwarancji będzie liczony odpowiednio od daty protokolarnego odbioru przedmiotu

Strona 158 z 204

zamówienia (protokół podpisany przez przedstawicieli Stron upoważnionych do dokonania tej

czynności).

Za najkorzystniejszą ofertę zostanie uznana oferta, która uzyska najwyższą liczbę punktów – „P”,

gdzie P oznacza sumę uzyskanych punktów w kryteriach cena oraz termin realizacji:

P = Cn + Fn+Gn

19. FORMALNOŚCI PO WYBORZE OFERTY NAJKORZYSTNIEJSZEJ

1. Zamawiający wyznaczy miejsce i termin zawarcia umowy. Umowę może podpisać

w imieniu Wykonawcy osoba (osoby) upoważniona (upoważnione) do reprezentowania

Wykonawcy, wymieniona w aktualnym odpisie z właściwego rejestru albo w aktualnym

zaświadczeniu o wpisie do centralnej ewidencji i informacji gospodarczej lub pełnomocnik, który

przedstawi pełnomocnictwo od osoby (osób) wymienionej w ww. dokumencie, udzielającej

pełnomocnictwa.

2. Jeżeli oferta Wykonawców wspólnie ubiegających się o zamówienie została wybrana jako

najkorzystniejsza, Wykonawcy przed zawarciem umowy zobowiązani są przedstawić

Zamawiającemu umowę regulującą ich współpracę.

20. WYMAGANIA DOTYCZĄCE ZABEZPIECZENIA NALEŻYTEGO

WYKONANIA UMOWY

1. Zamawiający żąda wniesienia zabezpieczenia należytego wykonania umowy (dalej

„Zabezpieczenie”), na pokrycie roszczeń z tytułu niewykonania lub nienależytego wykonania

umowy.

2. Zabezpieczenie ustala się w wysokości 1 % ceny brutto podanej w ofercie.

3. Zabezpieczenie należytego wykonania umowy należy wnieść przed podpisaniem umowy.

4. Zabezpieczenie może być wnoszone według wyboru Wykonawcy w jednej lub w kilku

następujących formach:

2) pieniądzu,

3) poręczeniach bankowych lub poręczeniach spółdzielczej kasy oszczędnościowo-kredytowej,

z tym, że zobowiązanie kasy jest zawsze zobowiązaniem pieniężnym z terminem ważności 30

dni od dnia wykonania zamówienia dla wartości 70% kwoty zabezpieczenia oraz z terminem

ważności 15 dni po upływie okresu rękojmi za wady dla wartości 30% kwoty zabezpieczenia;

4) gwarancjach bankowych – gwarancja będzie ona wystawiona z terminem ważności 15 dni po

upływie okresu rękojmi za wady oraz będzie zawierała postanowienie, że kwota 100%

zabezpieczenia zostanie, po upływie 30 dni od daty wykonania zamówienia i uznania przez

Zamawiającego za należycie wykonane, obniżona do kwoty stanowiącej 30% wysokości

zabezpieczenia, z przeznaczeniem na zabezpieczenie z tytułu rękojmi za wady,

Strona 159 z 204

5) gwarancjach ubezpieczeniowych – gwarancja będzie ona wystawiona z terminem ważności

15 dni po upływie okresu rękojmi za wady oraz będzie zawierała postanowienie, że kwota

100% zabezpieczenia zostanie, po upływie 30 dni od daty wykonania zamówienia i uznania

przez Zamawiającego za należycie wykonane, obniżona do kwoty stanowiącej 30%

wysokości zabezpieczenia, z przeznaczeniem na zabezpieczenie z tytułu rękojmi za wady

6) poręczeniach udzielanych przez podmioty, o których mowa w art. 6b ust. 5 pkt 2 ustawy z

dnia 9 listopada 2000 r. o utworzeniu Polskiej Agencji Rozwoju Przedsiębiorczości

7) poręczeniach udzielanych przez podmioty, o których mowa w art. 6b ust. 5 pkt 2 ustawy z

dnia 9 listopada 2000 r. o utworzeniu Polskiej Agencji Rozwoju Przedsiębiorczości.

5. Zasady jego wniesienia oraz zwrotu określają przepisy Ustawy;

6. Gwarancje muszą być złożone w formie oryginału i powinny zawierać następujące elementy:

1) bezwarunkowe zobowiązanie banku lub firmy ubezpieczającej do zapłaty ZNWU

na wezwanie Zamawiającego,

2) informację dotyczącą postępowania stanowiącego przyczynę wystawienia gwarancji

(określenie przedmiotu przetargu)

3) wskazanie sumy gwarancyjnej,

4) wskazanie Zamawiającego, czyli beneficjenta gwarancji,

5) wskazanie Wykonawcy, czyli zleceniodawcy gwarancji,

6) określenie terminu ważności gwarancji.

7. Poręczenia muszą być złożone w formie oryginału i powinny zawierać następujące elementy:

1) wskazanie podmiotu, za który bank lub podmioty, o których mowa w art. 6b, ust. 5, pkt. 2

ustawy z dnia 9 listopada 2000r. o utworzeniu Polskiej Agencji Rozwoju

Przedsiębiorczości (Dz. U. z 2007 r. Nr 42, poz. 275, z późn. zm.) dokonuje poręczenia,

2) precyzyjne wskazanie zobowiązania będącego przedmiotem poręczenia,

3) kwoty, do wysokości, której bank – poręczyciel lub podmioty, o których mowa

w art. 6b, ust. 5, pkt. 2 ustawy z dnia 9 listopada 2000r. o utworzeniu Polskiej Agencji Rozwoju

Przedsiębiorczości (Dz. U. z 2007 r. Nr 42, poz. 275, z późn. zm.) będą zobowiązane,

wskazanie terminu, z którego upływem wygasa zobowiązanie, przy czym poręczenie o charakterze

terminowym nie może zostać odwołane.

21. ISTOTNE POSTANOWIENIA UMOWY, UMOWA RAMOWA

1. Istotne postanowienia umowy stanowią Załącznik nr 11do SIWZ

2. Zamawiający nie przewiduje zawarcia umowy ramowej.

3. Zamawiający zgodnie z postanowieniami art. 144 ust. 1 ustawy Prawo zamówień publicznych

przewiduje możliwość zmiany postanowień zawartej umowy w stosunku do treści oferty, na

podstawie której dokonano wyboru Wykonawcy, jeżeli zmiany te wynikły z okoliczności,

których nie można było przewidzieć w chwili zawarcia umowy, w szczególności

w następujących sytuacjach:

1) gdy konieczność wprowadzenia modyfikacji wyniknie ze zmiany powszechnie

obowiązujących przepisów prawa, na mocy których na Zamawiającego lub Wykonawcę

nałożony zostanie obowiązek zrealizowania przedmiotu zamówienia w sposób różniący się od

zaoferowanego w ofercie lub obowiązek zmiany trybu wykonania zamówienia –

Strona 160 z 204

z zastrzeżeniem, że zmiana przepisów nie była uchwalona przed wszczęciem postępowania o

udzielenie zamówienia, w wyniku którego zawarto niniejszą umowę,

2) gdy podczas realizacji przedmiotu zamówienia zmianie ulegnie technologia wykonywania

robót na lepszą funkcjonalnie od technologii przewidzianej w ofercie, pod warunkiem, iż nie

spowoduje to zwiększenia kosztów realizacji zamówienia, a Wykonawca przed zmianą

umowy przedłoży Zamawiającemu do zaakceptowania projekt przewidywanych zmian w

inwestycji wraz z właściwym kosztorysem,

3) gdy podczas realizacji umowy wystąpią nieprzewidywalne na etapie zawierania umowy

okoliczności, które uniemożliwią zrealizowanie przedmiotu zamówienia w sposób

przewidziany w ofercie, a realizacja w tym zakresie zamówienia publicznego będzie

niemożliwa lub niecelowa ze względu na interes publiczny,

4) gdy podczas realizacji umowy wystąpią nieprzewidywalne na etapie zawierania umowy

okoliczności, które uniemożliwią zrealizowanie przedmiotu zamówienia w sposób

przewidziany w ofercie, a udzielenie w tym zakresie innego zamówienia publicznego w trybie

ustawy Prawo zamówień publicznych lub też będzie niemożliwe lub niecelowe ze względu na

interes publiczny,

4. Strony przewidują możliwość wprowadzenia – w formie pisemnego aneksu – zmiany

wysokości wynagrodzenia należnego Wykonawcy, w przypadku zmiany:

1) stawki podatku od towarów i usług,

2) wysokości minimalnego wynagrodzenia za pracę ustalonego na podstawie art. 2 ust. 3 – 5

ustawy z dnia 10 października 2002 r. o minimalnym wynagrodzeniu za pracę,

3) zasad podlegania ubezpieczeniom społecznym lub ubezpieczeniu zdrowotnemu lub wysokości

stawki składki na ubezpieczenie społeczne lub zdrowotne,

- jeżeli zmiany te będą miały wpływ na koszty wykonania zamówienia przez Wykonawcę.

5. Jeżeli zaktualizuje się którakolwiek z podstaw do zmiany wynagrodzenia, o której mowa w

poprzednim ustępie, Wykonawca zobowiązany jest poinformować o tym fakcie

Zamawiającego w terminie do 15 dni od dnia wystąpienia przyczyn wpływających na zmianę

kosztów wykonania zamówienia oraz zobowiązany jest przedstawić Zamawiającemu

szczegółową kalkulację zmiany wysokości swojego wynagrodzenia, opartą o przesłanki

wymienione w ust. 3. Zamawiający może żądać od Wykonawcy dodatkowych wyjaśnień

w zakresie odnoszącym się do przedstawionej kalkulacji, w tym w szczególności wyjaśnień,

których celem jest jednoznaczne i wyczerpujące wykazanie, w jaki sposób zmiany przepisów,

o których mowa w art. 142 ust. 5 ustawy Prawo zamówień publicznych, wpłynęły na koszt

wykonania zamówienia. Ewentualna zmiana wysokości wynagrodzenia będzie poprzedzona

badaniem dokumentów przedstawionych przez Wykonawcę i będzie następowała w oparciu o

aneks do umowy.

6. Żadna ze Stron nie może przelać na inny podmiot zobowiązań i uprawnień wynikających z

niniejszej umowy bez uprzedniej pisemnej zgody drugiej Strony.

22. WALUTY OBCE

Zamawiający nie przewiduje rozliczeń w walutach obcych.

23. KOSZTY UDZIAŁU W POSTĘPOWANIU

Wszelkie koszty związane z udziałem w postępowaniu (przygotowanie i złożenie

oferty) ponosi Wykonawca. Zamawiający nie przewiduje zwrotu kosztów udziału

w postępowaniu.

Strona 161 z 204

24. ŚRODKI OCHRONY PRAWNEJ

1. Środki ochrony prawnej przysługują wyłącznie od niezgodnej z przepisami ustawy Pzp czynności

Zamawiającego podjętej w postępowaniu o udzielenie zamówienia lub zaniechania czynności, do

której Zamawiający jest zobowiązany na podstawie ustawy Pzp.

2. Środki ochrony prawnej przysługują Wykonawcy, a także innemu podmiotowi, jeżeli ma lub miał

interes w uzyskaniu danego zamówienia oraz poniósł lub może ponieść szkodę w wyniku

naruszenia przez Zamawiającego przepisów ustawy.

3. Odwołanie wnosi się w terminie 10 dni od dnia przesłania informacji o czynności Zamawiającego

stanowiącej podstawę jego wniesienia – jeżeli zostały przesłane

w sposób określony w art. 180 ust. 5 ustawy Pzp zdanie drugie albo w terminie 15 dni – jeżeli

zostały przesłane w inny sposób.

4. Odwołanie wnosi się do Prezesa Izby w formie pisemnej lub w postaci elektronicznej, podpisane

bezpiecznym podpisem elektronicznym weryfikowanym przy pomocy ważnego kwalifikowanego

certyfikatu lub równoważnego środka, spełniającego wymagania dla tego rodzaju podpisu.

5. Odwołujący przesyła kopię odwołania Zamawiającemu przed upływem terminu do wniesienia

odwołania w taki sposób, aby mógł on zapoznać się z jego treścią przed upływem tego terminu.

Domniemywa się, iż Zamawiający mógł zapoznać się z treścią odwołania przed upływem terminu

do jego wniesienia, jeżeli przesłanie jego kopii nastąpiło przed upływem terminu do jego

wniesienia przy użyciu środków komunikacji elektronicznej.

6. Środki ochrony prawnej wobec ogłoszenia o zamówieniu oraz SIWZ przysługują również

organizacjom wpisanym na listę, o której mowa w art. 154 pkt 5 ustawy Pzp.

7. Szczegóły dotyczące odwołań i skarg określa DZIAŁ VI-ŚRODKI OCHRONY PRAWNEJ

ustawy.

25. ZAŁĄCZNIKI

1. Załącznik nr 1. Specyfikacja wymagań dla stacji roboczych.

2. Załącznik nr 2. Specyfikacja wymagań dla platformy serwerowej (opcjonalnie)

3. Załącznik nr 3. Specyfikacja urządzeń rozwiązania kolejkowego.

4. Załącznik nr 4. Formularz „Oferta” (w tym Zal.4a, stanowiący integralną część Formularza

Oferty).

5. Załącznik nr 5. Formularz „Jednolity Europejski Dokument Zamówienia - JEDZ”

6. Załącznik nr 6. Formularz „Wykaz dostaw”

7. Załącznik nr 7. Formularz „Wykaz osób”,

8. Załącznik nr 8. Formularz „Oświadczenie – grupa kapitałowa”

9. Załącznik nr 9. „Oświadczenie wykonawcy o braku orzeczenia wobec niego tytułem środka

zapobiegawczego zakazu ubiegania się o zamówienia publiczne”

Strona 162 z 204

10. Załącznik nr 10. „Oświadczenie wykonawcy o braku wydania wobec niego prawomocnego

wyroku sądu lub ostatecznej decyzji administracyjnej o zaleganiu z uiszczaniem podatków, opłat

lub składek na ubezpieczenia społeczne lub zdrowotne”

11. Załącznik nr 11. Istotne postanowienia umowy.

Strona 163 z 204

ZP/11/HIS+ERP/2020/UE

ZAŁĄCZNIK NR 4 DO SIWZ

FORMULARZ OFERTY

OFERTA w postępowaniu o udzielenie zamówienia publicznego prowadzonego w trybie przetargu

nieograniczonego na:

dostawę i wdrożenie systemu informatycznego e-Usługi wraz z modernizacją lub wymianą

zintegrowanego systemu zarządzania (HIS + ERP), systemów powiązanych i sprzętu

1. DANE WYKONAWCY

My/Ja* niżej podpisani ...........................................................................................................

/imię i nazwisko/

Reprezentując .......................................................................................................................................

/pełna nazwa Wykonawcy/

z siedzibą w:

...................................................................................................................................................................

...................................................................................................................................................................

adres e- mail: …………………………….. tel: ………………..………. fax: ……………………

NIP: ………………………………… REGON: …………………………………………

Osoba/osoby wyznaczone do reprezentowania Wykonawcy w celu podpisania umowy:

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

2. ŁĄCZNA CENA OFERTOWA

1. Oferujemy wykonanie zamówienia za ŁĄCZNĄ CENĘ OFERTOWĄ:

1) Brutto ……………………………PLN,

(Słownie …………………………………………………..)

Strona 164 z 204

Stawka VAT: …………. %

22. Netto ……………………………PLN

(Słownie …………………………………………………..)

w tym (części składowe ceny łącznej oferty):

23. LICENCJE I OPROGRAMOWANIE:

1) Brutto ……………………………PLN,

(Słownie …………………………………………………..)

Stawka VAT: …………. %

2) Netto ……………………………PLN

(Słownie …………………………………………………..)

2. WDROŻENIE ZSI:

1) Brutto ……………………………PLN,

(Słownie …………………………………………………..)

Stawka VAT: …………. %

2) Netto ……………………………PLN

(Słownie …………………………………………………..)

Strona 165 z 204

3. DOSTAWA URZĄDZEŃ:

1) Brutto ……………………………PLN,

(Słownie …………………………………………………..)

Stawka VAT: …………. %

2) Netto ……………………………PLN

(Słownie …………………………………………………..)

4. OFEROWANA ŁĄCZNA LICZBA DEKLARACJI TWIERDZĄCYCH „TAK” W

KRYTERIUM DODATKOWYCH FUNKCJONALNOŚCI SYSTEMU

Oferujemy funkcjonalność systemu, rozumianą jako sumę ilości twierdzących deklaracjiw liczbie,

zsumowanych zgodnie z Załącznikiem nr 4a do SIWZ, stanowiącego integralną część niniejszej

oferty.

5. OFEROWANY TERMIN GWARANCJI

Oferujemy udzielenie terminu gwarancji na przedmiot zamówienia na okres

…………… miesięcy, liczonych od daty protokolarnego odbioru asortymentu (protokół

podpisany przez przedstawicieli Stron upoważnionych do dokonania tej czynności).

6. Ponadto oświadczamy, że: 1. Zapoznaliśmy się ze Specyfikacją Istotnych Warunków Zamówienia i nie wnosimy do niej

zastrzeżeń.

2. Jestem / jesteśmy

mikroprzedsiębiorstwem TAK / NIE2

małymlubśrednimprzedsiębiorstwem TAK / NIE3

1. Uważamy się za związanych niniejszą ofertą na czas wskazany w Specyfikacji Istotnych

Warunków Zamówienia,

2. Akceptujemy dołączone do Specyfikacji Istotnych Warunków Zamówienia Istotne

2 Niepotrzebne skreślić.

3 Niepotrzebne skreślić.

Strona 166 z 204

Postanowienia Umowy (IPU) i zobowiązujemy się w przypadku wyboru naszej oferty do

zawarcia umowy na warunkach tam określonych, a także w miejscu i terminie wyznaczonym

przez Zamawiającego.

3. Zobowiązujemy się do złożenia wymaganych dokumentów stanowiących formalności przed

zawarciem umowy,

4. Oświadczamy, że oferowany przez nas przedmiot zamówienia odpowiada wymaganiom

określonym przez Zamawiającego w Specyfikacji Istotnych Warunków Zamówienia,

5. Oświadczamy, że oferta nie zawiera informacji stanowiących tajemnicę przedsiębiorstwa

w rozumieniu przepisów o zwalczaniu nieuczciwej konkurencji.*

Oświadczamy, że oferta zawiera informacje stanowiące tajemnicę przedsiębiorstwa w rozumieniu przepisów o zwalczaniu nieuczciwej konkurencji. Informacje takie zawarte są w następujących dokumentach * : ..……………………………………………………..;

6. Wadium w wysokości …………………….. zł, zostało wniesione w dniu ……………………. w formie ………………………………………………. .*

7. Wadium wniesione w formie pieniężnej należy zwrócić na konto Wykonawcy w …………………………….. , numer konta: ……………………………………………..*

9. Wykaz zakresu zamówienia, którą Wykonawca zamierza powierzyć Podwykonawcom*:

Lp. Nazwa (Firma)

Podwykonawcy

Zakres zamówienia

powierzony Podwykonawcy

Wykonawca korzysta z

potencjału podmiotu trzeciego

TAK/NIE

1

2

….

7. Oświadczenie w zakresie wypełnienia obowiązków informacyjnych

przewidzianych w art. 13 lub art. 14 RODO4

4rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku

z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne

rozporządzenie o ochronie danych) (Dz. Urz. UE L 119 z 04.05.2016, str. 1).

Strona 167 z 204

Oświadczam, że wypełniłem obowiązki informacyjne przewidziane w art. 13 lub art. 14 RODO1) wobec osób fizycznych, od których dane osobowe bezpośrednio lub pośrednio pozyskałem w celu ubiegania się o udzielenie zamówienia publicznego w niniejszym postępowaniu.*

WYKONAWCA

................................., dnia.…................... ……………………………………

/miejscowość i data/

/podpis osoby umocowanej prawnie do złożenia oświadczenia

woli wraz pieczęcią firmową/

* W przypadku gdy wykonawca nie przekazuje danych osobowych innych niż bezpośrednio jego dotyczących lub zachodzi

wyłączenie stosowania obowiązku informacyjnego, stosownie do art. 13 ust. 4 lub art. 14 ust. 5 RODO treści oświadczenia

wykonawca nie składa (usunięcie treści oświadczenia np. przez jego wykreślenie).

Strona 168 z 204

VII. Składając niniejszą ofertę, zgodnie z treścią art. 91 ust. 3a ustawy – Prawo zamówień publicznych

informujemy, że wybór oferty:

a. nie będzie prowadzić do powstania obowiązku podatkowego po stronie Zamawiającego,

zgodnie z przepisami o podatku od towarów i usług, który miałby obowiązek rozliczyć *

b. będzie prowadzić do powstania obowiązku podatkowego po stronie Zamawiającego, zgodnie z

przepisami o podatku od towarów i usług, który miałby obowiązek rozliczyć z tytułu *:

i. wewnątrzwspólnotowego nabycia towarów *,

ii. mechanizmu odwróconego obciążenia, o którym mowa w art. 17 ust. 1 pkt 7 ustawy o podatku

od towarów i usług *,

iii. importu usług lub importu towarów, z którymi wiąże się obowiązek doliczenia przez

Zamawiającego przy porównaniu cen ofertowych podatku VAT *

w następującym zakresie:

Lp. Nazwa usługi, której świadczenie będzie prowadzić do

powstania u Zamawiającego obowiązku podatkowego

Wartość bez kwoty

podatku VAT

(netto)

1

….

UWAGA!

W przypadku braku wskazania przez Wykonawcę powyższej informacji, Zamawiający uzna,

iż wybór oferty Wykonawcy nie będzie prowadzić do powstania obowiązku podatkowego po

stronie Zamawiającego, zgodnie z przepisami o podatku od towarów i usług, który miałby

obowiązek rozliczyć.

VIII. SPIS TREŚCI

1) Oferta zawiera ……………. ponumerowanych stron, w tym strony nr …………..... oferty są jawne,

natomiast strony nr ……….. oferty są niejawne*.

2) Załącznikami do niniejszej oferty, stanowiącymi jej integralną część, są:

(1)..........................................................................................

(2).........................................................................................., (…)

Strona 169 z 204

IX. PODPIS I PIECZĘĆ WYKONAWCY

Świadom odpowiedzialności karnej oświadczam, że załączone do oferty dokumenty i

oświadczenia opisują stan prawny i faktyczny, aktualny na dzień złożenia oferty (art. 297 KK).

WYKONAWCA

................................., dnia.…...................

/miejscowość i data/

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

/podpis osoby umocowanej prawnie do złożenia oświadczenia woli

wraz pieczęcią firmową/

* Należy uzupełnić, skreślić lub wpisać nie dotyczy

a. rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób

fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz

uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych) (Dz. Urz. UE L 119 z 04.05.2016, str. 1).

2. W przypadku gdy wykonawca nie przekazuje danych osobowych innych niż bezpośrednio jego dotyczących lub zachodzi

wyłączenie stosowania obowiązku informacyjnego, stosownie do art. 13 ust. 4 lub art. 14 ust. 5 RODO treści oświadczenia wykonawca nie składa (usunięcie treści oświadczenia np. przez jego wykreślenie).

Strona 170 z 204

Załącznik nr 4a do SIWZ

TABELA FUNKCJONALNOŚCI DODATKOWYCH

Wymagania posiadające różne poziomy realizacji podlegają punktacji i ocenie, o czym mowa w Rozdziale 9 SIWZ

Instrukcja wypełnienia tabeli:

W kolumnie „Spełnia TAK/NIE” należy wpisać słowo „Tak” w przypadku spełnienia określonego w wierszu wymogu funkcjonalnego (w

całości)

W kolumnie „Spełnia TAK/NIE” należy wpisać słowo „Nie” w przypadku gdy nie spełnienia określonego w wierszu wymogu funkcjonalności

(w całości)

Brak wpisu, nieczytelny wpis lub odpowiedź negatywna oznacza w kolumnie „Spełnia TAK/NIE” uznawany jest jako brak potwierdzenia danej

funkcjonalności dodatkowej i skutkuje nie uznaniem tej pozycji w sumowaniu odpowiedzi twierdzących, których suma będzie podstawiana do

wzoru celem wyliczenia uzyskanych punktów dla pozacenowego kryterium oceny ofert.

Pola zaznaczone znakiem „X” nie podlegają wypełnieniu.

Strona 171 z 204

L.p.

CZĘŚĆ BIAŁA HIS

Spełnia

TAK/NIE

I

DZIAŁANIE SYSTEMU

X

1

System działa z poziomu popularnych (Chrome, FireFox, Edge) przeglądarek internetowych i nie wymaga instalowania

dodatków/wtyczek do przeglądarek

2

System HIS działa z poziomu popularnych Chrome, FireFox, Edge) przeglądarek internetowych ale wymaga instalowania

dodatków/wtyczek do przeglądarek

Strona 172 z 204

II MONITORING KOMPLETNOŚCI DOKUMENTACJI X

1

System posiada aktywny monitoring kompletności dokumentacji lekarskiej i pielęgniarskiej wraz z możliwością wylistowania brakujących

dokumentów z poszczególnych dni z poziomu widoku kontekstu pacjenta

III OBSŁUGA FORMULARZY X

1

System ma możliwość tworzenia i zapisu przez uprawnionych użytkowników bez zaawansowanych kompetencji informatycznych całych

dokumentów w postaci formularzy do ponownego wykorzystania

2

System ma możliwości tworzenia i zapisu przez administratorów bez kompetencji programistycznych systemu formularzy do ponownego

wykorzystania

IV PREZENTACJA WYNIKÓW LABORATORYJNYCH X

1

System przedstawia interaktywne wykresy wyników laboratoryjnych prezentując zmiany koloru ekranu dla wyników badań

laboratoryjnych poza normą

V WIZUALIZACJA X

1

System ma możliwość oznaczania kolorami poszczególnych pól ekranu w celu zwrócenia uwagi na dane istotne z punktu widzenia

organizacji pracy danej komórki organizacyjnej

VI ZGŁOSZENIA CHOROBY NOWOTWOROWEJ DO REJESTRU NOWOTWORÓW X

1

System umożliwia importowanie i eksportowania zgłoszenia choroby nowotworowej do Rejestru Nowotworów

Strona 173 z 204

VII

UPRAWNIENIA

X

1

Kopiowanie praw dostępu między użytkownikami. System zapewnia możliwość kopiowania praw dostępu między użytkownikami

VIII

GROMADZENIE DANYCH W SYSTEMIE

X

1

Rejestr pacjentów. System ma jeden centralny rejestr pacjentów

IX

OBSŁUGA ZAŁĄCZNIKÓW

X

1

System posiada funkcjonalność dołączania załączników do dokumentacji Pacjenta bezpośrednio z urządzenia skanującego oraz ze skazanego

zasobu sieciowego

X

OBSŁUGA ODDZIAŁU

X

1 Wyszukiwanie pacjentów. System zapewnia możliwość zapisania szablonów filtrów wyszukiwania listy pacjentów oddziału

2

System ostrzeżeń.

System zapewnia możliwość wyświetlania ostrzeżeń na liście pacjentów oddziału co najmniej w zakresie:

- Skala Norton, REAL, TORRANCE΄A.

Strona 174 z 204

- Ocena stanu odżywienia

- Liczba dni od założenia aktualnego cewnika

- Liczba dni cewnikowania

- Odleżyny

- Liczba dni od zakończenia poprzedniej hospitalizacji na oddziale

- Czas przymusu bezpośredniego

Czas założonego wkłucia obwodowego przekraczający 72h

XI

ZAKAŻENIA SZPITALNE

X

1

System musi umożliwiać zgłoszenie podejrzenia zakażenia zarówno z poziomu oddziału jak i poradni

L.p. CZĘŚĆ BIAŁA E-USŁUGI

Spełnia

TAK/NIE

I

E-USŁUGI – PORTAL PACJENTA

X

1

Wielojęzyczność. Portal jest przystosowany do obsługi różnych języków, w zakresie zarówno elementów stałych strony WWW, jak i

zasobów przechowywanych w bazie danych (np. typy poradni, specjalizacje lekarzy, itp.) wraz z zapamiętywaniem wybranego przez

operatora języka. Wykonawca wraz z aplikacją dostarcza tłumaczenie elementów stałych strony WWW na wybrany język oraz konfiguruje

system centralny w taki sposób, aby Zamawiający mógł samodzielnie wprowadzać tłumaczenia zasobów w bazie danych.

Strona 175 z 204

POUCZENIE:

art. 297 § 1ustawy z dnia 6 czerwca 1997 r. - Kodeks karny (Dz.U.2017.0.2204 )

„Kto, w celu uzyskania dla siebie lub kogo innego (…) przedkłada podrobiony, przerobiony, poświadczający nieprawdę albo nierzetelny dokument albo nierzetelne, pisemne

oświadczenie dotyczące okoliczności o istotnym znaczeniu dla uzyskania (…) zamówienia, podlega karze pozbawienia wolności od 3 miesięcy do lat 5.”

...................................................................

(miejscowość/ data)

………………………………………………….

podpis/y osoby/osób upoważnionej/ych

do występowania w imieniu wykonawcy oraz pieczątka/ki imienna/e*

*pieczątka imienna w przypadku nieczytelnego podpisu

Strona 176 z 204

ZP/11/HIS+ERP/2020/UE

Załącznik nr 6 do SIWZ

WYKAZ DOSTAW

Nazwa Wykonawcy ....................................................................................................

Adres Wykonawcy .....................................................................................................

Numer telefonu ....................................................................................................

Adres e-mail …. ..............................................................................................

Przedmiot zamówienia

Wartość zamówienia Odbiorca Data wykonania zamówienia

-1- -2- -3- -4-

Na potwierdzenie należytego wykonania dostaw należy załączyć dowody określające czy te dostawy zostały wykonane należycie i prawidłowo ukończone, przy czy dowodami, o których mowa są referencje bądź inne dokumenty wystawione przez podmiot, na rzecz którego dostawy zostały wykonane, a jeżeli z uzasadnionej przyczyny o obiektywnym charakterze Wykonawca nie jest w stanie uzyskać tych dokumentów – inne dokumenty np. „Protokół odbioru końcowego wdrożonego systemu”.

POUCZENIE:

art. 297 § 1ustawy z dnia 6 czerwca 1997 r. - Kodeks karny (Dz.U.2017.0.2204 )

„Kto, w celu uzyskania dla siebie lub kogo innego (…) przedkłada podrobiony, przerobiony, poświadczający

nieprawdę albo nierzetelny dokument albo nierzetelne, pisemne oświadczenie dotyczące okoliczności o istotnym

znaczeniu dla uzyskania (…) zamówienia, podlega karze pozbawienia wolności od 3 miesięcy do lat 5.”

...................................................................

(miejscowość/ data)

………………………………………………….

podpis/y osoby/osób upoważnionej/ych

do występowania w imieniu wykonawcy oraz pieczątka/ki imienna/e*

*pieczątka imienna w przypadku nieczytelnego podpisu

Strona 177 z 204

ZP/11/HIS+ERP/2020/UE

Załącznik nr 7 do SIWZ

……………………………….

Nazwa i adres wykonawcy

(pieczątka firmowa)

WYKAZ OSÓB, KTÓRE ZOSTANĄ SKIEROWANE PRZEZ WYKONAWCĘ DO REALIZACJI ZAMÓWIENIA PUBLICZNEGO

w szczególności odpowiedzialnych za świadczenie usług, wraz z informacjami na temat ich kwalifikacji zawodowych, uprawnieńdoświadczenia i

wykształcenia, etc., niezbędnych do wykonania zamówienia publicznego, a także zakresu wykonywanych przez nie czynnościoraz informacją o

podstawie do dysponowania tymi osobami

KIEROWNIK PROJEKTU

Lp. NAZWISKO I IMIĘ

Wykształcenie

Kwalifikacje

zawodowe (specjalność oraz

Odzaje posiadanych

CERYFIKATÓW)

Doświadczenie w rozumieniu odniesieniu do wykonanych

projektów tożsamych z przedmiotem zamówienia *

Wartość wykonanej

usługi

(zł)

Podstawa

dysponowania osobą **

oraz miejsce

zatrudnienia

Szczegółowy opis wykonanej

USŁUGI na stanowisku

Kierownika projektu

(w tym zakres wykonywanych

czynności, pełna nazwa zadania)

oraz

pełne dane podmiotu na rzecz

którego były świadczone

Termin wykonania

zamówienia – data

rozpoczęcia oraz

zakończenia (dzień-miesiąc-

rok)

Strona 178 z 204

1 2

3 4 5 6 7 9

1

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

…………………………..

………………………

………………………

…………………………

…………………………

………………

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

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

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

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

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

………………………..

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

…………………………

……………………………..

2

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

…………………………..

………………………

………………………

…………………………

…………………………

………………

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

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

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

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

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

………………………..

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

…………………………

……………………………..

Strona 179 z 204

ARCHITEKT SYSTEMÓW INFORMATYCZNYCH

Lp. NAZWISKO I IMIĘ

Wykształcenie

Kwalifikacje

zawodowe (specjalność oraz

Odzaje posiadanych

CERYFIKATÓW)

Doświadczenie w rozumieniu odniesieniu do wykonanych

projektów tożsamych z przedmiotem zamówienia *

Wartość wykonanej

usługi

(zł)

Podstawa

dysponowania osobą **

oraz miejsce

zatrudnienia

Szczegółowy opis wykonanej

USŁUGI na stanowisku

Architekta systemów

(w tym zakres wykonywanych

czynności, pełna nazwa zadania)

oraz

pełne dane podmiotu na rzecz

którego były świadczone

Termin wykonania

zamówienia – data

rozpoczęcia oraz

zakończenia (dzień-miesiąc-

rok)

1 2

3 4 5 6 7 9

1

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

…………………………..

………………………

………………………

…………………………

…………………………

………………

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

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

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

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

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

………………………..

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

…………………………

……………………………..

2

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

………………………….. ………………………

………………………

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

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

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

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

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

………………………..

…………………………

Strona 180 z 204

…………………………

…………………………

………………

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

…………………………

……………………………..

UWAGA!

* w kwestii przeliczenia miesięcy ma zastosowanie regulacja art. 112 lub 113 ustawy z dnia 23 kwietnia 1964 r. - Kodeks cywilny (Dz.U.2018.0.1025).

** Podstawa dysponowania osobą np.:

- osoba jest pracownikiem Wykonawcy (umowa o pracę w rozumieniu przepisów ustawy z dnia 26 czerwca 1974 r.- Kodeks pracy)

- osoba fizyczna nie będąca pracownikiem Wykonawcy (umowa zlecenie, umowa o dzieło)

- umowa z innym podmiotem

Art.22a- Wykonawca może w celu potwierdzenia spełniania warunków udziału w postępowaniu, w stosownych sytuacjach oraz w odniesieniu do konkretnego

zamówienia, lub jego części, polegać na zdolnościach technicznych lub zawodowych lub sytuacji finansowej lub ekonomicznej innych podmiotów,

niezależnie od charakteru prawnego łączących go z nim stosunków prawnych. Wykonawca, który polega na zdolnościach lub sytuacji innych

podmiotów, musi udowodnić zamawiającemu, że realizując zamówienie, będzie dysponował niezbędnymi zasobami tych podmiotów, w

szczególności przedstawiając zobowiązanie tych podmiotów do oddania mu do dyspozycji niezbędnych zasobów na potrzeby realizacji zamówienia.

Wykonawca, który polega na sytuacji finansowej lub ekonomicznej innych podmiotów, odpowiada solidarnie z podmiotem, który zobowiązał

się do udostępnienia zasobów, za szkodę poniesioną przez zamawiającego powstałą wskutek nieudostępnienia tych zasobów, chyba że za

nieudostępnienie zasobów nie ponosi winy.

POUCZENIE:

art. 297 § 1ustawy z dnia 6 czerwca 1997 r. - Kodeks karny (Dz.U.2017.0.2204 )

Strona 181 z 204

„Kto, w celu uzyskania dla siebie lub kogo innego (…) przedkłada podrobiony, przerobiony, poświadczający nieprawdę albo nierzetelny dokument albo

nierzetelne, pisemne oświadczenie dotyczące okoliczności o istotnym znaczeniu dla uzyskania (…) zamówienia, podlega karze pozbawienia wolności od 3

miesięcy do lat 5.”

...................................................................

(miejscowość/ data)

………………………………………………….

podpis/y osoby/osób upoważnionej/ych

do występowania w imieniu wykonawcy oraz pieczątka/ki imienna/e*

*pieczątka imienna w przypadku nieczytelnego podpisu

Strona 182 z 204

ZP/11/HIS+ERP/2020/UE

Załącznik nr 8 do SIWZ

PRZYNALEŻNOŚCI LUB BRAKU PRZYNALEŻNOŚCI DO TEJ SAMEJ GRUPY

KAPITAŁOWEJ

o której mowa w art. 24 ust. 1 pkt 23 Ustawy z dnia 29 stycznia 2004 r. prawo zamówień publicznych

(Dz. U. z 2018 r., poz. 1986 ze zm.),

zwanej dalej Ustawą pzp.

Składając ofertę w postępowaniu o zamówienie publiczne na: dostawę i wdrożenie systemu

informatycznego e-Usługi wraz z modernizacją lub wymianą zintegrowanego systemu zarządzania

(HIS + ERP), systemów powiązanych i sprzętu świadomy odpowiedzialności karnej wynikającej ze

składania fałszywych oświadczeń - niniejszym oświadczam, co następuje:

1. Ja niżej podpisany .................................................................................................................................

oświadczam, iż podmiot przeze mnie reprezentowany nie należy do grupy kapitałowej, o której

mowa w art. 24 ust. 1 pkt. 23 Ustawy pzp, w rozumieniu ustawy z dnia 16 lutego 2007 o ochronie

konkurencji i konsumentów (Dz. U. z 2018 r., poz. 798 z późn. zm).

2. Ja niżej podpisany ...............................................................................................................................

oświadczam, iż podmiot przeze mnie reprezentowany należy do grupy kapitałowej, o której mowa

w art. 24 ust. 1 pkt. 23 Ustawy pzp, w rozumieniu ustawy z dnia 16 lutego 2007 o ochronie

konkurencji i konsumentów (Dz. U. z 2018 r., poz. 798 z późn. zm).

Jednocześnie na podstawie art. 26 ust. 2 d Ustawy pzp, składam poniżej listę podmiotów

należących do w/w grupy kapitałowej, które złożyły odrębne oferty w niniejszym postępowaniu:

.............................................

............................................

3. Jednocześnie oświadczam, że istniejące między podmiotami wskazanymi w pkt. 2 powiązanie nie

prowadzą do zakłócenia konkurencji w postępowaniu o udzielenie zamówienia ponieważ:

..................................................................................................................................................................

..................................................................................................................................................................

.......................................................................................................................................................

...................... , ......................... .........................................

(miejscowość, data) ( pieczęć, podpis)

Strona 183 z 204

UWAGA

Zgodnie z art. 86 ust. 5 ustawy Pzp, oświadczenie to składa wykonawca w terminie 3 dni od dnia zamieszczenia na

stronie internetowej informacji.

W przypadku, w którym Wykonawca nie należy do grupy kapitałowej należy skreślić pkt. 2 jako nie dotyczy.

W przypadku, w którym Wykonawca należy do grupy kapitałowej - składa listę podmiotów należących do tej samej

grupy kapitałowej, które złożyły w niniejszym postępowaniu oraz odpowiednio wypełnia pkt. 3

W przypadku Wykonawców wspólnie ubiegających się o zamówienie powyższe oświadczenie składa każdy członek

konsorcjum.

Strona 184 z 204

ZP/11/HIS+ERP/2020/UE

Załącznik nr 9do SIWZ

(pieczęć adresowa Wykonawcy)

OŚWIADCZENIE WYKONAWCY

DOTYCZĄCE BRAKU ORZECZENIA TYTUŁEM ŚRODKA ZAPOBIEGAWCZEGO

ZAKAZU UBIEGANIA SIĘ O ZAMÓWIENIA PUBLICZNE

Dotyczy oferty złożonej w postępowaniu o udzielenie zamówienia publicznego prowadzonym

w trybie przetargu nieograniczonego na dostawę i wdrożenie systemu informatycznego e-Usługi wraz z

modernizacją lub wymianą zintegrowanego systemu zarządzania (HIS + ERP), systemów

powiązanych i sprzętu,

nrsprawy: ZP/11/HIS+ERP/2020/UE,

ja/my (imię nazwisko)…………………………………………………………………………….....

...................................................................................................................................................................

reprezentując firmę (nazwa firmy).............................................................................................................

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

jako pełnomocny przedstawiciel reprezentowanej przeze mnie firmy oświadczam/ my,iż wobec mnie /

nas:

nie wydano orzeczenia tytułem środka zapobiegawczego zakazu ubiegania się o zamówienie

publiczne.

wydano orzeczenie tytułem środka zapobiegawczego zakazu ubiegania się o zamówienie publiczne

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

(wpisać sygnaturę wyroku/nr decyzji administracyjnej, datę wydania, czego dotyczy)

Oświadczam, że wszystkie informacje podane w powyższym oświadczeniu są aktualne

i zgodne z prawdą oraz zostały przedstawione z pełną świadomością konsekwencji wprowadzenia

Zamawiającego w błąd przy przedstawianiu informacji.

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

(data i podpis i pieczątka imienna osoby upoważnionej do

składania oświadczeń woli

w imieniu Wykonawcy)

Strona 185 z 204

ZP/11/HIS+ERP/2020/UE

Załącznik nr 10 do SIWZ

(pieczęć adresowa Wykonawcy)

OŚWIADCZENIE WYKONAWCY

DOTYCZĄCE BRAKU WYDANIA PRAWOMOCNEGO WYROKU SĄDU LUB OSTATECZNEJ DECYZJI

ADMINISTRACYJNEJ

Dotyczy oferty złożonej w postępowaniu o udzielenie zamówienia publicznego prowadzonym

w trybie przetargu nieograniczonego na dostawę i wdrożenie systemu informatycznego e-Usługi wraz z

modernizacją lub wymianą zintegrowanego systemu zarządzania (HIS + ERP), systemów

powiązanych i sprzętu,

nrsprawy: ZP/11/HIS+ERP/2020/UE

ja/my (imię nazwisko)……………………………………………………………………………….....

...................................................................................................................................................................

reprezentując firmę (nazwa firmy).............................................................................................................

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

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

jako pełnomocny przedstawiciel reprezentowanej przeze mnie firmy oświadczam/ my,iż wobec mnie /

nas:

nie wydano prawomocnego wyroku sądu lub ostatecznej decyzji administracyjnej o zaleganiu

z uiszczaniem podatków, opłat lub składek na ubezpieczenia społeczne lub zdrowotne, albo

wydano prawomocny wyrok sądu lub ostateczną decyzję administracyjną o zaleganiu

z uiszczaniem podatków, opłat lub składek na ubezpieczenia społeczne lub zdrowotne. W celu

wykazania braku podstaw do wykluczenia na podstawie art. 24 ust. 1 pkt 15) ustawy Pzp

przedstawiamy w załączeniu dokumenty potwierdzające dokonanie płatności ww. należności wraz

z ewentualnymi odsetkami lub grzywnami lub zawarcie wiążącego porozumienia

w sprawie spłat tych należności.

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

(data i podpis i pieczątka imienna osoby upoważnionej

do składania oświadczeń woli w imieniu Wykonawcy)

Strona 186 z 204

ZP/11/HIS+ERP/2020/UE

Załącznik nr 11 do SIWZ

ISTOTNE POSTANOWIENIA UMOWY

na dostawę i wdrożenie systemu informatycznego e-Usługi wraz z modernizacją lub wymianą

zintegrowanego systemu zarządzania (HIS + ERP), systemów powiązanych i sprzętu

§ 1 DEFINICJE

Terminy pisane w Umowie wielką literą mają następujące znaczenie:

1. Analiza Przedwdrożeniowa – analiza zakończona raportem zawierającym opis

wymagańdotyczących ZSI w odniesieniu do poszczególnych obszarów Wdrożenia i procesów

biznesowych wraz z diagramami tych procesów (w formie docelowej).

2. Aplikacja – częśćskładowa ZSI, charakteryzująca sięspójnym zakresem

merytorycznymrealizowanych funkcji i procesów, wykonująca swoje procedury we wzajemnej

interakcji z innymi aplikacjami wchodzącymi w skład ZSI i zdolna do samodzielnego działania

w oderwaniu od innych aplikacji ZSI.

3. BI – rozwiązanie Business Intelligence, wchodzący w skład ZSI i objęty zakresem

Wdrożeniasystem informowania kierownictwa klasy business intelligence (BI) oparty o

wielowymiarową bazę danych typu OLAP wraz z warstwą prezentacji raportów i analiz.

4. Błąd Krytyczny – nieprawidłowośćfunkcjonowania ZSI, mająca kluczowe znaczenie,

bezktórej poprawne działanie i użytkowanie ZSI jest niemożliwe lub przestaje być zasadne, w

szczególności, gdy niemożliwy jest poprawny zapis i odczyt danych.

5. Błąd Niekrytyczny – nieprawidłowośćfunkcjonowania ZSI uniemożliwiająca lub

znacznieutrudniająca wykonanie funkcji, bez której korzystanie z ZSI jest znacznie utrudnione,

mimo że możliwy jest poprawny zapis i odczyt danych.

6. Błąd Oprogramowania – Błąd Krytyczny, Błąd Niekrytyczny, Usterka lub inne

działanieZSI, użytkowanego we właściwych warunkach eksploatacji, które jest niezgodnie

ze specyfikacją, dokumentacją, założoną logiką i nie zostało spowodowane przez co

najmniej jedną z następujących przyczyn:

a. zastosowanie oprogramowania w sposób niezgodny z przeznaczeniem,

b. błędne wprowadzenie danych przez użytkownika,

c. użytkowanie oprogramowania na sprzęcie komputerowym niespełniającym

minimalnych parametrów, a w szczególności parametrów wydajnościowych

określonych dla wskazanej ilości stanowisk i producenta motoru bazy danych

oraz Oprogramowania Systemowego,

d. użytkowanie oprogramowania w sieci logicznej LAN,

Strona 187 z 204

e. działanie wirusa komputerowego,

f. niewłaściwa parametryzacja ZSI, Oprogramowania Systemowego oraz motoru bazy danych, z którym współpracuje, z wyłączeniem sytuacji, w której zostało to wykonane przez Wykonawcę,

g. modyfikacja lub ingerencja w ZSI przez Zamawiającego lub osoby trzecie

h. zmiana dokonana przez Zamawiającego w systemach dziedzinowych urządzeń, z którymi współpracuje oprogramowanie, w szczególności w programach sterujących aparatów diagnostycznych,

i. niewykonanie przez Zamawiającego uaktualnień Oprogramowania Systemowego zalecanych przez jego producentów,

j. brak zgłoszenia niepomyślnego wykonania aktualizacji ZSI przez Zamawiającego i dalsza eksploatacja ZSI mimo pojawiania się błędów (dotyczy także logów),

k. niezastosowanie się Zamawiającego do zaleceń producentów Oprogramowania Systemowego w zakresie jego eksploatacji.

7. Dokumentacja Użytkowa - podręcznik w formie papierowej lub elektronicznej,

zawierającyopis użytkowy oprogramowania oraz instrukcję jego obsługi w języku polskim.

8. Dokumentacja Projektowa – opis rozwiązania dokumentujący przyszły kształt procesów

wZSI (obsługę procesów w systemie) opracowany na podstawie mapowania wymagań na

system, w tym projekt ustawień (konfiguracji) systemu, słowników, itd.

9. EOD – tzw. Elektroniczny Obieg Dokumentów, wchodzące w skład ZSI i objęte

zakresemWdrożenia specjalistyczne oprogramowanie realizujące funkcje automatyzujące

czynności i procedury kancelaryjne (w tym obsługę korespondencji

wchodzącej/wychodzącej) i dotyczące obiegu dokumentów w Szpitalu według jej

wewnętrznej instrukcji obiegu dokumentów, stanowiące element ZSI.

2

Strona 188 z 204

10. ERP – Enterprise Resource Planning, klasa systemów informatycznych

wspomagającychzarządzanie przedsiębiorstwem, do której należy ZSI.

11. Etap Wdrożenia – etap Wdrożenia ustalony w Harmonogramie

Szczegółowymprzedstawionym przez Wykonawcę po wykonaniu Analizy Przedwdrożeniowej.

12. Harmonogram Szczegółowy – szczegółowy harmonogram rzeczowo-

finansowyWdrożenia, przedstawiony przez Wykonawcę po wykonaniu Analizy

Przedwdrożeniowej, zawierający szczegółowy wykaz prac i produktów przypadających na dany

Etap Wdrożenia, a także wartość tych prac i produktów.

13. Harmonogram Wdrożenia - oznacza ogólny harmonogram Wdrożenia wraz z podziałem

naEtapy Wdrożenia zgodnie z OPZ.

14. HIS - Hospital Information System, system informatyczny wspomagający funkcjonowanie

izarządzanie Szpitala w zakresie obsługi pacjenta, zarządzania ruchem chorych, obsługi

procedur medycznych i procesów leczenia pacjentów.

15. Infrastruktura Zamawiającego – infrastruktura informatyczna Zamawiającego, w

tymsprzęt i oprogramowanie, opisana w OPZ.

16. Integracja – integracja ZSI oraz HIS zapewniająca ich interoperacyjnośćw zakresie

niemniejszym niż wskazany w OPZ.

17. Kierownik Wykonawcy – przedstawiciel Wykonawcy, którego zakres

obowiązkówwskazano w OPZ.

18. Kierownik Zamawiającego – przedstawiciel Zamawiającego, którego zakres

obowiązkówwskazano w OPZ.

19. Kierownictwo Wdrożenia – zespół, którego rola opisana została w OPZ.

20. LIS – Laboratory Information System, system informatyczny wspomagający gromadzenie,

przechowywanie i przetwarzanie danych medycznych wytwarzanych przez laboratorium

diagnostyki medycznej oraz zarządzanie laboratorium.

21. Moduł ZSI – część składowa ZSI, charakteryzująca sięspójnym zakresem merytorycznym

realizowanych funkcji i procesów, wykonująca swoje procedury we wzajemnej interakcji z

innymi aplikacjami wchodzącymi w skład ZSI. Moduł ZSI nie jest zdolny do samodzielnego

działania w oderwaniu od ZSI.

22. Nośnik – fizyczny środek (materiał lub urządzenie) przechowujący lub przeznaczony do

przechowywania w nim danych (ciągów symboli), w szczególności CD, DVD, FDD, HDD,

SDD, pendrive.

23. Oferta – oferta Wykonawcy z dnia [ ] złożono w postępowaniu przeprowadzonym w trybie

przetargu nieograniczonego pod znakiem PN/02HIS/01/2018 z dnia [ ] roku.

Strona 189 z 204

24. Oprogramowanie Bazodanowe – oprogramowanie umożliwiające gromadzenie,

przechowywanie i udostępnianie zorganizowanych danych, najczęściej motor bazy danych typu

SQL (motor bazy danych).

25. Oprogramowanie Systemowe – oprogramowanie zarządzające systemem komputerowym,

tworzące środowisko do uruchamiania i kontroli zadań użytkownika lub udostępniania usług w

sieci.

26. OPZ – Opis Przedmiotu Zamówienia stanowiący załącznik nr [ ] do SIWZ.

27. PACS - Picture Archiving and Communication System, system informatyczny

wspomagający gromadzenie, udostępnianie i wymianę obrazów medycznych.

28. Poprawka – obejmuje zmiany niekwalifikowane jako Usługi Rozwoju lub aktualizacja

związane z eliminacją zidentyfikowanych Błędów Oprogramowania, zmianami interfejsu,

usprawnieniem działania funkcji lub procesów, niewprowadzające nowych rozwiązań.

29. RIS - Radiology Information System, system informatyczny wspomagający

przechowywanie, przetwarzanie i udostępnianie radiologicznych obrazów medycznych.

SIWZ – specyfikacja istotnych warunków zamówienia w postępowaniu przeprowadzonym w

trybie przetargu nieograniczonego pod znakiem PN/02HIS/01/2018 z dnia [ ] roku.

30. Stacja Robocza – oznacza komputer klasy PC lub terminal z monitorem używany przez

Użytkownika, na którym będzie użytkowany ZSI.

31. Szpital - oznacza Szpital Praski Sp. z o.o. w Warszawie wraz ze wszystkimi jednostkami

organizacyjnymi.

32. Umowa – niniejsza umowa wraz z załącznikami.

33. Usługi Utrzymania -świadczone przez Wykonawcę usługi utrzymania związane z

zapewnieniem poprawnej pracy ZSI, szczegółowo określone w SIWZ oraz w Umowie.

34. Usługi Rozwoju -świadczone przez Wykonawcę usługi rozwoju ZSI.

35. Wdrożenie –dostawa ZSI, instalacja, konfiguracja, Integracja, integracja z LIS, RIS i

PACS, testy, których celem jest wdrożenie i uruchomienie ZSI w przedsiębiorstwie

Zamawiającego, którego szczegółowy zakres został opisany w OPZ.

36. Wynagrodzenie – wynagrodzenie ryczałtowe brutto za Wdrożenie i Usługi Utrzymania

wskazane w §11 Umowy.

37. Dostawca ERP – podmiot, który będzie dostawcą oprogramowania ERP, który zostanie

wyłoniony w ramach innego postępowania przetargowego.

38. Usterka – nieprawidłowość w pracy oprogramowania, bez usunięcia której

oprogramowanie może normalnie funkcjonować, lecz jego użytkowanie jest utrudnione.

Strona 190 z 204

39. Urządzenia Eksploatacyjne - specjalistyczne urządzenia niezbędne do prawidłowego

funkcjonowania i eksploatacji oprogramowania inne niż Stacje Robocze, w tym urządzenia

peryferyjne (drukarki, skanery, czytniki kodów kreskowych, kolektory danych).

40. Użytkownik – oznacza osobę należącą do personelu Zamawiającego, posiadającą

uprawnienia do korzystania z ZSI.

41. ZSI – zintegrowany system informatyczny typu HIS, stanowiący funkcjonalny zbiór

współdziałających i współpracujących ze sobą aplikacji opisanych w SIWZ, wykonujący swoje

procedury we wzajemnej interakcji, realizujący procesy biznesowe Szpitala, będący

przedmiotem Wdrożenia.

§ 2 PRZEDMIOT UMOWY

1. Przedmiotem Umowy jest w szczególności:

a. wykonanie Analizy Przedwdrożeniowej; b. wykonanie Wdrożenia, w szczególności zainstalowanie ZSI w Infrastrukturze

Zamawiającego, przetestowanie i uruchomienie ZSI, przeprowadzenie szkoleń, zapewnienie licencji na korzystanie z ZSI;

c. udzielenie gwarancji jakości na ZSI;

d. świadczenie Usług Serwisowych; e. podjęcie wszystkich działań przewidzianych w SIWZ służących wykonaniu

zamówienia zgodnie z OPZ i Ofertą. 2. Szczegółowy zakres Wdrożenia został określony w OPZ.

§ 3 ZOBOWIĄZANIA WYKONAWCY

1. Wykonawca jest zobowiązany realizować przedmiot Umowy przy współpracy

z Zamawiającym, w szczególności poprzez:

1) udział, co najmniej raz w tygodniu, w naradach Kierownictwa Wdrożenia,

odbywających się w siedzibie Zamawiającego lub innym miejscu wskazanym przez

Zamawiającego, których przedmiotem będzie omówienie bieżącego postępu prac,

zagadnień istotnych dla Wdrożenia, proponowanych przez Wykonawcę rozwiązań,

jak również zagadnień mających wpływ na przedmiot i termin realizacji Wdrożenia;

2) udział w spotkaniach zorganizowanych przez Zamawiającego, dotyczących

realizacji Umowy, zwoływanych w sytuacjach nadzwyczajnych zaistniałych w toku

realizacji Umowy, na każde wezwanie Zamawiającego,

3) niezwłoczne informowanie Zamawiającego o nieprawidłowościach lub

przeszkodach w terminowej realizacji Umowy.

2. Wykonawca jest zobowiązany do sporządzania raportów miesięcznych oraz raportów na

zakończenie Etapu Wdrożenia i przedkładania ich Zamawiającemu. Raporty powinny

zawierać informacje dotyczące: postępu wykonywanych prac, kosztów i ryzyk,

osiągniętych wskaźników, ewentualnych opóźnień, przyczyn nieosiągnięcia

zakładanych rezultatów, przewidywanych zagrożeń realizacji Umowy. Wykonawca

zobowiązany jest składać raporty w następujących terminach:

1) raporty miesięczne – do 5 dnia każdego miesiąca kalendarzowego

następującego po miesiącu, którego raport dotyczy,

Strona 191 z 204

2) raporty na zakończenie Etapu Wdrożenia – w terminie 10 dni od dnia

zakończenia danego Etapu Wdrożenia.

3. Wykonawca zobowiązany jest do:

1) dołożenia najwyższej staranności realizując świadczenia na rzecz

Zamawiającego;

2) dążenia do rozwiązań optymalnych, w szczególności ze względu na

niezawodność, wydajność i ergonomię (prostotę i szybkość obsługi) i koszt;

3) pełnej współpracy z Zamawiającym w celu przekazania Zamawiającemu

wiedzy na temat przedmiotu realizowanych usług i dostaw, na zasadach

określonych w Umowie;

4) terminowego wykonywania zobowiązań. Wykonawca będzie przy tym

zobowiązany do bezzwłocznego informowania Zamawiającego, jeśli

zamówione usługi lub dostawy nie będą mogły być w całości lub w części

wykonane, określając powody zaistniałej sytuacji oraz wskazując możliwe

rozwiązania tej sytuacji;

5) przekazywania Zamawiającemu informacji na temat przedmiotu

wykonywanych usług i realizowanych dostaw, poprzez wykonywanie tych

usług w taki sposób, aby umożliwić Zamawiającemu zapoznawanie się z ich

rezultatami;

6) udzielenia licencji na oprogramowanie własne oraz pośredniczenia w

udzieleniu licencji na oprogramowanie osób trzecich.

4. Wykonawca jest uważany za profesjonalistę w zakresie przedmiotu Umowy i wykonania Wdrożenia. Niezależnie od zakresu wiedzy informatycznej i organizacyjnej, którądysponuje Zamawiający, Zamawiający nie jest uważany za profesjonalistę w dziedzinie przedmiotu Umowy o poziomie porównywalnym do Wykonawcy. Strony ustalają, że Wykonawca nie może powoływać się na oświadczenia Zamawiającego w zakresie wskazanym w zdaniu poprzednim, w celu ograniczenia odpowiedzialności Wykonawcy, chyba że Wykonawca poinformuje Zamawiającego na piśmie o swoich zaleceniach orazo ryzykach niezastosowania się do nich, a Zamawiający mimo to podejmie decyzję pozostającą w sprzeczności z tymi zaleceniami. Powyższe ograniczenie nie wyłącza możliwości powoływania się przez Wykonawcę, w celu ograniczenia odpowiedzialności, na treść oświadczeń Zamawiającego w zakresie wiedzy informatycznej i organizacyjnej znajdującej się w wyłącznej dyspozycji Zamawiającego, niezbędnej dla należytego wykonania obowiązków przez Wykonawcę.

5. Jeżeli Wykonawca posługuje się przy realizacji umowy podwykonawcami lub dalszymi

podwykonawcami, Wykonawca ponosi odpowiedzialność za ich działania i zaniechania

jak za swoje własne działania i zaniechania. Zamawiający w każdym czasie

obowiązywania umowy ma prawo żądać od Wykonawcy przedstawienia informacji

dotyczących podwykonawców oraz dalszych podwykonawców zawierającej w

szczególności: wykaz podwykonawców lub dalszych podwykonawców uczestniczących

w realizacji umowy ze wskazaniem: nazwy i siedziby podwykonawcy lub dalszego

podwykonawcy, zakres prac lub dostaw powierzonych podwykonawcy. Przez umowy o

podwykonawstwo strony rozumieją pisemne umowy o charakterze odpłatnym, których

przedmiotem są usługi, dostawy stanowiące część niniejszej umowy, a co najmniej

jednym innym podmiotem (podwykonawcą), a także między podwykonawcą.

6. Wykonawca zobowiązuje się do należytego zabezpieczenia i przechowywania

wszelkich dokumentów, w szczególności dokumentów finansowych dotyczących

Umowy, dla ewentualnych przyszłych potrzeb instytucji krajowych i Unii Europejskiej,

Strona 192 z 204

upoważnionych do kontroli Projektu oraz udostępniania ww. dokumentów do wglądu w

granicach wynikających z przepisów prawa.

7. Wykonawca zobowiązuje się do wykonywania umowy między innymi przy pomocy osób wskazanych w treści oferty dla wykazania spełniania warunków udziału w postępowaniu.

8. Zmiana osób wskazanych w §15 Umowy może nastąpić jedynie za pisemną zgodą

Zamawiającego. Zgoda zostanie udzielona wyłącznie w sytuacji, w której

zaproponowana osoba posiada takie same lub wyższe kwalifikacje zawodowe i

doświadczenie w stosunku do osoby, której dotyczyć ma zmiana.

§ 4 ZOBOWIĄZANIA ZAMAWIAJĄCEGO

1. Zamawiający zobowiązany jest do współdziałania z Wykonawcą w celu umożliwienia

mu realizacji niniejszej Umowy, w szczególności poprzez:

1) dostarczanie wszelkich informacji dotyczących przedsiębiorstwa i wymagań

Zamawiającego, o które wystąpi Wykonawca, w takim zakresie, w jakim

będzie to niezbędne do wykonywania przez Wykonawcę wynikających z

Umowy zobowiązań na rzecz Zamawiającego

2) odbiór wykonanego i wdrożonego ZSI oraz Usług Wdrożeniowych i zapłatę

za nie;

3) terminowe wywiązywanie się ze szczegółowych obowiązków uzgodnionych z

Wykonawcą

4) zapewnienia dostępu do Infrastruktury Zamawiającego w godzinach od 7:00

do 15:00 w dni robocze lub w innych dniach i godzinach po wcześniejszym

uzgodnieniu z Wykonawcą;

5) każdorazowego zawiadamiania Wykonawcy o istotnych czynnikach,

o których Zamawiający posiada wiedzę, a które mogą mieć wpływ na

realizację Umowy. 2. Zamawiający wyznaczy Kierownika Zamawiającego odpowiedzialnego za wdrożenie [ ]

po stronie Zamawiającego: 1) ze znajomością przebiegu procesów w przedsiębiorstwie;

2) dostępnego przez cały okres Wdrożenia, w celu dostarczania niezbędnych

informacji;

3) odpowiedzialnego za wdrażanie nowych pracowników i komunikację z

osobami odpowiedzialnym za Wdrożenie.

§ 5 TERMINY WYKONANIA UMOWY 1. Wykonawca zobowiązuje się zrealizować dokonać Wdrożenia zgodnie z

Harmonogramem Wdrożenia, lecz nie później niż do dnia …………………..2020 roku. 2. Wykonawca zobowiązuje się do przedłożenia Zamawiającemu raportu z Analizy

Przedwdrożeniowej w terminie do 4 tygodni od dnia zawarcia Umowy. 3. Wykonawca zobowiązuje się świadczyć Usługi Serwisowe przez okres

…………..(zgodnie z pozacenowym kryterium oceny ofert)miesięcy, liczonych od dnia

podpisania Protokołu Odbioru Końcowego. 4. Zamawiający przewiduje możliwość zmiany Umowy w zakresie terminu jej wykonania

umowy, w razie zaistnienia jednego lub kilku z następujących przypadków: 1) wyrażenia zgody przez Mazowiecką Jednostkę Wdrażania Programów Unijnych na

zmianę terminu zakończenia rzeczowej realizacji projektu lub terminu zakończenia

realizacji projektu w zakresie zadania „Zapewnienie wysokiej jakości usług

medycznych poprzez wdrożenie e-usług w Szpitalu Praskim Sp. z o.o.

Strona 193 z 204

2) w przypadku uzyskania przez projekt statusu niefunkcjonującego lub

niezakończonego i częściowo funkcjonującego zgodnie z decyzją KE z dnia 20

marca 2013 r. C(2013) 1573 w sprawie zatwierdzenia wytycznych dotyczących

zamknięcia programów operacyjnych przyjętych do celów pomocy z EFRR, EFS i

FS (2007-2013).

§ 6 ZASADY DOKONYWANIA ODBIORÓW

1. Po prawidłowym wykonaniu danego Etapu Wdrożenia Strony podpiszą Protokół

Odbioru Etapu Wdrożenia, zgodnie ze wzorem stanowiącym załącznik nr [ ] do

Umowy. Za prawidłowe wykonanie danego Etapu Wdrożenia uznaje się spełnienie

przez dany Etap Wdrożenia kryteriów odbioru wskazanych w Harmonogramie

Wdrożenia oraz Harmonogramie Szczegółowym. 2. Wykonanie Wdrożenia zostanie potwierdzone podpisaniem Protokołu Odbioru

Końcowego przez obie Strony zgodnie ze wzorem stanowiącym załącznik nr [ ] do Umowy.

3. Przed przystąpieniem do odbioru Etapu Wdrożenia, Wykonawca jest zobowiązany do

przesłania Zamawiającemu, nie później niż w terminie 5 dni roboczych przed

wskazanym w Harmonogramie Wdrożenia terminem zakończenia Etapu Wdrożenia,

pisemnego zawiadomienia o gotowości do przystąpienia do danego odbioru, który

powinien zawierać co najmniej wskazanie przedstawionego do odbioru Etapu

Wdrożenia oraz termin i miejsce rozpoczęcia odbioru.

4. Zamawiający, w terminie do 10 dni roboczych, liczonych od dnia przekazania danego

Etapu Wdrożenia do odbioru, uprawniony jest do zgłaszania zastrzeżeń, jeśli prace lub

produkty nie spełniają kryteriów opisanych w OPZ. Niezwłocznie po otrzymaniu pełnej,

pisemnej listy uwag od Zamawiającego, Wykonawca usunie nieprawidłowości lub

uzupełni braki i ponownie przekaże dany Etap Wdrożenia do odbioru. 5. Odbiór całości Wdrożenia uważa się za dokonany, gdy zostanie odebrany ostatni Etap

Wdrożenia i podpisany zostanie Protokół Odbioru Końcowego. 6. Podstawowym kryterium Odbioru Wdrożenia jest brak Błędów Oprogramowania oraz

brak innych niezgodności z Umową. 7. Wykonawca jest zobowiązany do przekazania Zamawiającemu Dokumentacji

Użytkowej najpóźniej w dniu podpisania Protokołu Odbioru Końcowego. 8. Miejscem poszczególnych odbiorów, o których mowa w Umowie jest siedziba

Zamawiającego. 9. Zamawiający dokona odbioru Dokumentacji Projektowej zgodnie z podanym poniżej

postępowaniem: 1) w terminie 7 dni roboczych od dnia przedłożenia przez Wykonawcę Dokumentacji

Projektowej, może zaakceptować Dokumentację Projektową bez zastrzeżeń lub

zgłosić do niej zmiany. Niezgłoszenie zmian przez Zamawiającego skutkować

będzie przyjęciem, z dniem upływu terminu, o którym mowa w zdaniu

poprzedzającym, że Zamawiający nie zgłasza zmian do przedłożonej mu do

zaakceptowania Dokumentacji Projektowej;

2) Wykonawca ustosunkuje się w formie pisemnej do zmian zaproponowanych przez

Zamawiającego w terminie 3 dni roboczych od dnia ich zgłoszenia; w takim

przypadku Zamawiający zobowiązany jest w terminie 7 dni od dnia

ustosunkowania się Wykonawcy, o którym mowa w zdaniu poprzedzającym, do

zaakceptowania propozycji Wykonawcy lub ponownego zgłoszenia zmian; w

takim przypadku zdanie drugie punktu 1) stosuje się odpowiednio;

3) po przeprowadzeniu procedury akceptacji opisanej w pkt 1 i 2 w przypadku gdy

Zamawiający nie zaakceptuje stanowiska Wykonawcy bez uwag, Zamawiający

może przedstawić zmiany do Dokumentacji Projektowej, a Wykonawca będzie

Strona 194 z 204

nimi związany; zmiany wprowadzane przez Zamawiającego w trybie niniejszego

ustępu muszą być zgodne z powszechnie obowiązującym przepisami prawa oraz

zawierać się w zakresie wyznaczonym treścią Umowy oraz OPZ.

§ 7 ZABEZPIECZENIE NALEŻYTEGO WYKONANIA UMOWY

1. Ustala się zabezpieczenie należytego wykonania Umowy w wysokości 1% kwoty całkowitej wynagrodzenia wskazanego w §13 ust. 1 Umowy, tj. na kwotę [ ] złotych (słownie: [ ] złotych). Zabezpieczenie wniesione zostało na rzecz Zamawiającego.

2. Wykonawca wniósł zabezpieczenie należytego wykonania Umowy na wartość określoną w §7.1 Umowy, przed podpisaniem Umowy, w formie [ ]

3. Pod warunkiem braku roszczeń Zamawiającego związanych z nienależytym wykonaniem lub niewykonaniem Umowy, Zamawiający zwróci Wykonawcy zabezpieczenie należytego wykonania Umowy w następujących transzach:

1) 70% wysokości zabezpieczenia należytego wykonania Umowy, wniesionego na zabezpieczenie roszczeń Zamawiającego – w terminie 30 dni od dnia podpisania Protokołu Odbioru Końcowego przez Zamawiającego,

2) 30% wysokości zabezpieczenia należytego wykonania Umowy, wniesionego na zabezpieczenie roszczeń Zamawiającego – nie później niż w terminie 15 dni od dnia upływu terminu gwarancji jakości, o którym mowa w §8.2 Umowy.

§ 8 RĘKOJMIA ZA WADY I GWARANCJA

1. Odpowiedzialność z tytułu rękojmi za wady Wykonawca ponosi na zasadach określonych w Kodeksie Cywilnym przez okres [ ]miesięcy od dnia podpisania Protokołu Odbioru Końcowego.

2. Wykonawca udziela Zamawiającemu gwarancji jakości na całe dostarczone

oprogramowanie i zrealizowane Wdrożenie na okres [ ] miesięcy oraz gwarantuje, iż wdrożony ZSI będzie posiadał cechy i parametry wskazane w SIWZ oraz OPZ.

§ 9 USŁUGI UTRZYMANIA 1. W okresie gwarancji jakości Wykonawca będzie świadczył Usługi Utrzymania w

ramach których: 1) będzie usuwał Błędy Oprogramowania na warunkach i w terminach określonych

Umową; 2) zapewni dostępność ZSI zgodnie z wymaganiami Zamawiającego oraz

funkcjonalności dodatkowych zaoferowanych w ramach pozacenowego kryterium

oceny ofert; 3) zapewni aktualizację ZSI, w tym dostosowanie ZSI do zmieniających się przepisów

prawa; 4) zapewnieni konsultacje w siedzibie Zamawiającego w wymiarze 5 godzin w ciągu

każdego miesiąca Usług Utrzymania. 2. Każdy miesiąc świadczenia Usług Utrzymania będzie potwierdzany odpowiednim

raportem. Raport zostanie przygotowany przez Wykonawcę w terminie 10 dni po zakończeniu danego miesiąca i będzie określał co najmniej:

1) liczbę zgłoszonych Błędów i Usterek wraz z opisem naprawy (numer zgłoszenia, kwalifikację zgłoszenia, godzinę i datę zgłoszenia, temat zgłoszenia, status zgłoszenia, godzinę i datę dostarczenia rozwiązania zastępczego, godzinę i datęusunięcia Błędu lub Usterki, godzinę i datę wykonania reakcji Wykonawcy, czas naprawy, czas opóźnienia w postaci godzin lub dni dla rozwiązania zastępczego lub usunięcia Błędu lub Usterki)

Strona 195 z 204

2) opis przekazanych Poprawek, uaktualnień itp.

3. Wykonawca zobowiązuje się do świadczenia Usług Utrzymania w sposób

zapobiegający utracie danych Zamawiającego, w tym także tych, do których będzie miał

dostęp w trakcie wykonywania usług. W przypadku gdy wykonanie danej czynności

przez Wykonawcę lub przez Zamawiającego w oparciu o rekomendację Wykonawcy

wiąże się z ryzykiem utraty danych, Wykonawca zobowiązany jest poinformować o tym

Zamawiającego przed przystąpieniem do wykonania takiej czynności lub z chwilą

przekazania takiej rekomendacji Zamawiającemu.

4. W przypadku ujawnienia Błędów Oprogramowania w okresie gwarancji jakości, Wykonawca jest zobowiązany do nieodpłatnego dokonania ich naprawy.

5. Zamawiający będzie dokonywał zgłoszeń gwarancyjnych:

1) na adres internetowy e-mail: [ ];

2) pod numerem telefonu [ ];

3) poprzez system zgłoszeń on-line.

6. System zgłoszeń on-line dostarczy nieodpłatnie Wykonawca (będzie on utrzymywany i

administrowany przez Wykonawcę). 7. Za skuteczne przyjęcie zgłoszenia Błędu Oprogramowania uważa się wprowadzenie

przez Zamawiającego wpisu zawierającego opis zgłaszanego Błędu Oprogramowania i

termin jego zgłoszenia. W razie trudności z dostępem on-line do systemu zgłoszeń,

zgłoszenia Błędu Oprogramowania mogą odbywać się telefonicznie pod ustalonym

numerem telefonu lub pisemnie na formularzu przesyłanym na ustalony adres e-mail.

8. W ramach gwarancji Wykonawca będzie przyjmował zgłoszenia Błędów

Oprogramowania od poniedziałku do piątku od 7:00 do 17:00 i będzie zobowiązany do

przystąpienia do naprawy w ciągu 4 kolejnych godzin pracy serwisu licząc od chwili

dokonania zgłoszenia Błędu Oprogramowania. 9. W ramach gwarancji jakości Wykonawca będzie usuwał Błędy Oprogramowania w

następującym czasie liczonym od upływu czasu na przystąpienie do naprawy: 1) Błędu Krytycznego – 48 godzin;

2) Błędu Niekrytycznego – 7 dni;

3) Usterki – 30 dni. 10. Dopuszcza się zmianę kwalifikacji zgłoszenia Błędu Oprogramowania po uprzedniej

zgodzie Zamawiającego. Do czasu potwierdzenia zmiany kwalifikacji za obowiązującą uznaje się kwalifikację dokonaną pierwotnie przez Zamawiającego.

11. W przypadku braku możliwości usunięcia Błędu Oprogramowania lub przedstawienia rozwiązania zastępczego zdalnie, Wykonawca zobowiązany jest do świadczenia w ramach udzielonej gwarancji jakości bezpośrednio w siedzibie Zamawiającego.

12. Usunięcie Błędu Oprogramowania, nastąpi poprzez przekazanie Poprawki lub nowej

wersji ZSI. Każda Poprawka lub nowa wersja ZSI musi posiadać unikalny numer.

Zasady wersjonowania Poprawek i nowych wersji zostaną ustalone przez Wykonawcę

w Dokumentacji Projektowej.

13. W ramach gwarancji jakości Wykonawca w przypadku konieczności dokonania

modyfikacji ZSI zobowiązany jest do: 1) wykonywania modyfikacji bez wezwania lub na pisemne zgłoszenie Zamawiającego

w celu dostosowania wszystkich elementów ZSI do obowiązujących przepisów prawnych;

Strona 196 z 204

2) przekazania Zamawiającemu informacji o nowych wersjach ZSI drogą elektroniczną na wskazany adres e-mail Zamawiającego;

3) udostępniania nowych wersji ZSI poprzez ustaloną witrynę internetową, w

szczególności związanych z wejściem w życie nowych przepisów prawa lub

zawierających nowe funkcjonalności, w szczególności związane z rozliczeniami z

NFZ; w przypadku w którym udostępnianie, o którym mowa w niniejszy punkcie

następować będzie w związku ze zmianą przepisów prawa, Wykonawca

zobowiązany będzie do jej dokonania na nie mniej niż 14 dni przed dniem wejścia

w życie tych przepisów;

4) wysłania na adres korespondencyjny Zamawiającego nośnika CD/DVD zawierającego nową wersję ZSI, na pisemne żądanie wniesione przez Zamawiającego;

5) każda nowa wersja ZSI musi posiadać unikalny numer; zasady wersjonowania nowych wersji zostaną przekazane przez Wykonawcę w Dokumentacji Projektowej;

6) wraz z nową wersją ZSI Wykonawca zobowiązany jest do przekazania nowej wersji Dokumentacji Użytkowej wraz z procedurą instalacji oraz informacją o parametryzacji i konfiguracji.

14. Wykonawca w ramach gwarancji jakości zobowiązany jest do świadczenia usług w postaci konsultacji, porad, wsparcia technicznego w zakresie wdrożenia oraz użytkowania ZSI przy czym:

1) usługi będą świadczone w dni robocze w godzinach od 8.00 do 16.00;

2) tryb zgłaszania: telefonicznie, e-mail, faxem lub poprzez system zgłoszeń on-line;

3) konsultacje i porady będą udzielane na bieżąco podczas rozmowy telefonicznej lub

w postaci elektronicznej, jeżeli wynika to z przedmiotu usługi, jednak nie później

niż w ciągu 3 dni roboczych od skierowania zapytania. Jeżeli nie jest możliwe

wykonanie usługi w ciągu 3 dni roboczych Wykonawca uzgodni z danym

Zamawiającym inny termin konsultacji lub porady.

15. W ramach świadczonych usług wsparcia powdrożeniowego, udzielonej gwarancji oraz

nadzoru autorskiego producenta/producentów oprogramowania Wykonawca zapewni

Zamawiającemu bez dodatkowego wynagrodzenia, w okresie świadczenia Usług

Utrzymania, wsparcie w zakresie ewentualnej integracji systemu wykonanego lub

dostarczonego w ramach Umowy z innym systemem informatycznym Zamawiającego,

obejmujące:

1) określenie listy baz danych systemu wykonanego lub dostarczonego w ramach Umowy ze wskazaniem ich ilości i rodzajów (proste czy złożone, relacyjne czy obiektowe);

2) określenie pełnej listę modułów/podsystemów systemu wykonanego lub dostarczonego w ramach Umowy, których dotyczyć będzie integracja danych ze wskazaniem technicznych informacji, dzięki którym możliwa będzie integracja;

3) podanie struktury poszczególnych baz danych systemu wykonanego lub dostarczonego w ramach Umowy;

4) podanie rozmiaru baz danych systemu wykonanego lub dostarczonego w ramach Umowy;

5) określenie sposobu integracji z systemem wykonanym lub dostarczonym w ramach Umowy ze wskazaniem na dane, które mają pierwszeństwo;

6) podanie informacji na temat spójności danych; 7) wsparcie w przygotowaniu pliku w formacie CSV lub XLS, zawierający dane do

integracji oraz dokumentację umożliwiającą identyfikację zawartości tych plików.

Strona 197 z 204

§ 10 USŁUGI ROZWOJU

1. Wykonawca w okresie [ ] miesięcy od dnia podpisania Protokołu Odbioru Końcowego

zobowiązuje się świadczyć Usługi Rozwoju, w tym dokonywania modyfikacji ZSI, w

szczególności poprzez tworzenie dodatkowych Modułów ZSI lub Aplikacji, zgodnie z

oczekiwaniami Zamawiającego. 2. Usługi Rozwoju to usługi, których wykonanie nie wynika z Błędu Oprogramowania lub

zmian przepisów prawa. 3. Zamawiający przekaże Wykonawcy zlecenie świadczenia Usług Rozwoju, w którym

określi: 1) przedmiot Usług Rozwoju;

2) oczekiwany termin wykonania Usług Rozwoju. 4. Wykonawca w terminie 7 dni od dnia otrzymania zlecenia Zamawiającego wystosuje do

Zamawiającego ofertę obejmującą: 1) wynagrodzenie za Usługi Rozwoju objęte zleceniem; 2) potwierdzenie terminu realizacji zleconych Usług Rozwoju lub propozycję nowego

terminu. 5. Zamawiający po otrzymaniu odpowiedzi Wykonawcy może:

1) potwierdzić zlecenie Usług Rozwoju zgodnie z treścią zlecenia i odpowiedzi Wykonawcy;

2) złożyć oświadczenie o rezygnacji z realizacji danych Usług Rozwoju objętych zleceniem;

3) zaprosić Wykonawcę do negocjacji celem ustalenia zakresu, wynagrodzenia i terminu realizacji Usług Rozwoju.

§ 11 WYNAGRODZENIE I WARUNKI PŁATNOŚCI 1. Z tytułu należytej realizacji Umowy, Zamawiający zapłaci Wykonawcy ryczałtowe

wynagrodzenie w łącznej wysokości [ ] złotych netto, w tym: 1) 90% Wynagrodzenia z tytułu Wdrożenia;

2) 10% Wynagrodzenia z tytułu świadczenia Usług Utrzymania. Wynagrodzenie, o którym mowa w §11.1 Umowy zostanie powiększone o należny podatek VAT.

2. Wynagrodzenie, o którym mowa w §11.1 Umowy obejmuje wynagrodzenie za wszelkie

świadczenia Wykonawcy konieczne do wykonania Umowy, w tym ryzyko Wykonawcy

z tytułu oszacowania wszelkich kosztów związanych z realizacją przedmiotu Umowy,

a także oddziaływania innych czynników mających lub mogących mieć wpływ na

koszty. Wykonawcy nie przysługują żadne inne roszczenia w stosunku do

Zamawiającego, w szczególności zwrot kosztów podróży oraz zakwaterowania

członków personelu Wykonawcy czy też zwrot jakichkolwiek innych, dodatkowych

kosztów ponoszonych przez Wykonawcę związanych z wykonywaniem Umowy.

3. Wynagrodzenie, o którym mowa w: 1) Umowy będzie płatne częściami po każdorazowym dokonaniu odbioru Etapu

Wdrożenia stosownie do Harmonogramu Szczegółowego i zgodnie z zaawansowaniem Wdrożenia;

Umowy będzie płatne w równych miesięcznych ratach przez okres świadczenia Usług Utrzymania.

Strona 198 z 204

4. Zamawiający dokona zapłaty przelewem na rachunek bankowy wskazany w fakturze. Zapłata zostanie dokonana w terminie 30 dni od dnia doręczenia faktury Zamawiającemu.

5. Podstawą wystawienia faktury w zakresie Wdrożenia jest odpowiedni Protokół Odbioru Etapu Wdrożenia oraz Protokół Odbioru Końcowego.

6. Podstawą wystawienia faktury w zakresie Usług Utrzymania jest przedstawienie odpowiedniego raportu ze świadczenia Usług Utrzymania.

7. Wykonawca zobowiązany jest do wystawienia i doręczenia faktur VAT w terminie do 7

dni od dnia podpisania Protokołów Odbioru Etapu Wdrożenia lub Protokołu Odbioru

Końcowego. W przypadku uchybienia obowiązkowi wynikającemu ze zdania

poprzedzającego, Wykonawca zobowiązany będzie do naprawienia szkody wynikającej

z ewentualnego uznania płatności dokonywanych przez Zamawiającego za wydatki

niekwalifikowane.

§ 12 KARY UMOWNE 1. Zamawiający jest uprawniony do domagania się od Wykonawcy zapłaty kar umownych

w wysokości: 1) 0,2% Wynagrodzenia za każdy rozpoczęty dzień zwłoki w zakończeniu Etapu

Wdrożenia w stosunku do terminów wskazanych w Harmonogramie Wdrożenia; 2) 0,25% Wynagrodzenia za każdy rozpoczęty dzień zwłoki w dokonaniu Wdrożenia

w stosunku do terminu wskazanego w Harmonogramie Wdrożenia; 3) 0,05% Wynagrodzenia za każdy przypadek nieprzystąpienia do wykonania Usług

Utrzymania w terminie wskazanym w Umowie; 4) 0,05% Wynagrodzenia za każdą rozpoczętą godzinę zwłoki, liczoną od upływu

terminu w godzinach wyznaczonego jako czas reakcji, w usunięciu Błędu Krytycznego;

5) 0,0025% Wynagrodzenia za każdy rozpoczęty dzień zwłoki w usunięciu Błędu Niekrytycznego lub Usterki;

6) 20% Wynagrodzenia w przypadku odstąpienia od Umowy przez Zamawiającego lub wypowiedzenia Umowy przez Zamawiającego z powodu okoliczności, za które odpowiedzialność ponosi Wykonawca;

2. Zapłata kary umownej nie wyłącza możliwości dochodzenia przez Zamawiającego odszkodowania na zasadach ogólnych do wysokości rzeczywiście poniesionej szkody.

3. W przypadku, w którym na skutek przyczyn leżących po stronie Wykonawcy dojdzie do

utraty dofinansowania przez Zamawiającego, Zamawiający uprawniony będzie do

dochodzenia od Wykonawcy na zasadach ogólnych odszkodowania w wysokości

odpowiadającej wysokości utraconej części dofinansowania.

§ 13 PRAWA WŁASNOŚCI INTELEKTUALNEJ

1. Wykonawca jest odpowiedzialny za zapewnienie Zamawiającemu, w ramach

Wynagrodzenia, o którym mowa w §13.1 Umowy, wszelkich praw własności

intelektualnej koniecznych do korzystania z ZSI zgodnie z jego przeznaczeniem, w tym

w szczególności nabycie przez Zamawiającego uprawnień wynikających z licencji

udzielanych przez producentów oprogramowania dostarczanego w ramach Wdrożenia.

2. Z chwilą podpisania Protokołu Odbioru Końcowego, Wykonawca przekaże

Zamawiającemu wszelkie certyfikaty licencyjne do oprogramowania, którego

producentem nie jest Wykonawca, które będą potwierdzały uprawnienie Zamawiającego

do korzystania z ZSI i pozostałego oprogramowania w zakresie wynikającym z Umowy.

3. W odniesieniu do oprogramowania, którego producentem jest Wykonawca, z chwilą

podpisania Protokołu Odbioru Końcowego, Wykonawca, w ramach Wynagrodzenia, o

Strona 199 z 204

którym mowa w §13.1 Umowy, udziela Zamawiającemu, na czas nieokreślony, bez

ograniczeń terytorialnych, licencji niewyłącznej na korzystanie z ZSI. 4. Licencje na korzystanie z oprogramowania dostarczonego w ramach Wdrożenia

obejmują nieograniczone terytorialnie i czasowo uprawnienie do korzystania z oprogramowania w całości lub w części, na następujących polach eksploatacji:

1) trwałego lub czasowego zwielokrotnienia oprogramowania w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie; w szczególności w zakresie, w którym jest to niezbędne dla wprowadzania, wyświetlania, stosowania, przekazywania i przechowywania dla potrzeb Zamawiającego, z uwzględnieniem prawa Zamawiającego do sporządzania kopii zapasowych oprogramowania w celach bezpieczeństwa i archiwalnych;

1) tłumaczenia, przystosowywania, zmiany układu lub jakichkolwiek innych zmian w oprogramowaniu;

2) połączenia z jakimkolwiek oprogramowaniem, sprzętem komputerowym lub usługami, w szczególności w celu eksploatacji baz danych, raportów, zestawień stworzonych przy wykorzystaniu oprogramowania i ich pobierania i obróbki.

5. Jeśli autorskie prawa majątkowe do jakiegokolwiek utworu powstałego lub

wykorzystanego w ramach wykonania Umowy, a w szczególności do oprogramowania,

przysługują osobie trzeciej, Wykonawca zobowiązany jest uzyskać skuteczne prawo do

korzystania z tych utworów w zakresie przewidzianym Umową oraz udzielić

Zamawiającemu licencji lub sublicencji na korzystanie z nich, na warunkach i przez

czasokreślony Umową, o ile warunki licencyjne producenta oprogramowania, którym

nie jest Wykonawca, załączone do umowy w postaci certyfikatów licencyjnych, nie

sprzeciwiają się temu. Wykonawca oświadcza i gwarantuje przy tym, że zakres licencji

do korzystania z takiego oprogramowania obcego i dokumentacji do tego

oprogramowania będzie co najmniej taki, aby umożliwić Zamawiającemu normalne i

niezakłócone korzystanie z oprogramowania zgodnie z przeznaczeniem i w pełnym

zakresie funkcjonalności.

6. Zamawiający może upoważnić inne osoby do korzystania z utworu w zakresie uzyskanej licencji w celu rozwoju oprogramowania dostarczonego na podstawie Umowy.

7. Wykonawca oświadcza, że w razie wystąpienia do Zamawiającego przez osobę trzecią z

jakimikolwiek roszczeniami w związku z utworami, w odniesieniu do których

Wykonawca udzielił licencji, Wykonawca niezwłocznie dostarczy Zamawiającemu

dokumenty wykazujące jego prawa do utworów objętych licencją, a w przypadku

wystąpienia przez tę osobę trzecią na drogę sądową, do zgłoszenia interwencji ubocznej

po stronie Zamawiającego oraz do zwrotu Zamawiającemu wszelkich kosztów

procesowych i wartości odszkodowań wypłaconych przez Zamawiającego w związku z

koniecznością zaspokojenia takich roszczeń

8. Jeżeli wskutek roszczeń zgłoszonych przez osoby trzecie Zamawiający nie będzie mógł

korzystać z ZSI, Wykonawca zobowiązany będzie do uzyskania na swój koszt

wymaganych licencji lub nabycia praw pozwalających na korzystanie z nich.

Wykonawca może zwolnić się z powyższego obowiązku poprzez dokonanie

odpowiedniej modyfikacji ZSI, która pozwoli Zamawiającemu na korzystanie z ZSI

zgodnie z prawem, przy czym Wykonawca zobowiązany jest naprawić szkodę, jaką

Zamawiający poniósł wskutek niemożności korzystania z ZSI, w tym także za czas

dokonania odpowiednich modyfikacji przez Wykonawcę.

Strona 200 z 204

9. Wykonawca zobowiązuje się do niewypowiadania licencji w okresie pierwszych 5 lat ich trwania. Wykonawca może wypowiedzieć licencje z zachowaniem 10-letniego okresu wypowiedzenia ze skutkiem na koniec roku kalendarzowego.

10. Strony postanawiają, że w razie wątpliwości co do zakresu licencji powinna ona być

interpretowana z uwzględnieniem, że zamiarem Stron było udzielenie Zamawiającemu

licencji w najszerszym możliwym zakresie niezbędnym w celu umożliwienia

Zamawiającemu: 1) samodzielnej eksploatacji, konserwacji, modernizacji, naprawy ZSI, w taki sposób,

aby Zamawiający był uprawniony do wykorzystywania ZSI w pełnym zakresie wynikającym z potrzeb jego działalności gospodarczej;

2) samodzielnego wprowadzenia, lub zlecenia wprowadzania przez podmioty trzecie, zmian do ZSI, rozwijania lub tworzenia jego nowych funkcjonalności i korzystania z nich.

11. Postanowienia Umowy nie ograniczają i nie wyłączają uprawnień Zamawiającego w odniesieniu do ZSI określonych przepisami ustawy o prawie autorskim i prawach pokrewnych.

12. Wszystkie dostarczone licencje mają być zainstalowane w ZSI, z określeniem uprawnień do ich wykorzystywania na Stacjach Roboczych lub Serwerach.

§ 14 ROZWIĄZANIE UMOWY 1. Zamawiającemu przysługuje prawo do odstąpienia od Umowy, bez wyznaczania

dodatkowego terminu, z przyczyn leżących po stronie Wykonawcy w wypadku: 1) przekroczenia terminu zakończenia Etapu Wdrożenia, o którym mowa w § [ ]

Umowy o więcej niż 20 dni;

2) przekroczenia terminu zakończenia Wdrożenia, o którym mowa w § [ ] Umowy o więcej niż 30 dni;

3) przekroczenia terminu usunięciu Błędu Oprogramowania, o którym mowa w §[ ] Umowy o więcej niż 10 dni;

2. Odstąpienie od Umowy jest skuteczne z dniem doręczenia drugiej Stronie pisemnego zawiadomienia wraz z uzasadnieniem. Oświadczenie o odstąpieniu niezawierające uzasadnienia jest bezskuteczne.

3. W przypadku odstąpienia od Umowy:

1) Zamawiający zwróci Wykonawcy lub usunie w sposób uniemożliwiający

produkcyjne wykorzystanie wszelkie świadczenia Wykonawcy związane z

Wdrożeniem, a Wykonawca zobowiązany będzie zwrócić otrzymane

Wynagrodzenie w terminie 30 dni od daty otrzymania oświadczenia

Zamawiającego o odstąpieniu od Umowy;

2) Zamawiający w każdym przypadku będzie uprawniony do zatrzymania

pojedynczych kopii świadczeń związanych z Wdrożeniem na potrzeby

ewentualnego dochodzenia roszczeń przysługujących Zamawiającemu w

stosunku do Wykonawcy lub osób trzecich lub ochrony przed roszczeniami

takich osób; 3) z tytułu korzystania przez Zamawiającego z usług lub innych świadczeń w

okresie od ich dostarczenia przez Wykonawcę, do dnia ich zwrotu lub

Strona 201 z 204

zniszczenia Wykonawcy nie przysługuje jakiekolwiek wynagrodzenie lub odszkodowanie.

§ 15 PRZEDSTAWICIELE STRON

1. Przedstawicielami Zamawiającego w toku realizacji Umowy będą:

1) [ ] – Kierownik Zamawiającego - uprawniony do reprezentowania

Zamawiającegow zakresie dokonywania wszelkich czynności faktycznych i

prawnych związanych z realizacją Umowy.

2. Przedstawicielami Wykonawcy w toku realizacji Umowy będą:

1) [ ] – Kierownik Wykonawcy - uprawniony do reprezentowania Wykonawcy

wzakresie dokonywania wszelkich czynności faktycznych i prawnych

związanych z realizacją Umowy. 3. Zmiana lub powołanie nowych przedstawicieli Stron wymaga pisemnego

powiadomienia drugiej Strony, lecz nie stanowi zmiany Umowy.

§ 16 INTEGRACJA 1. Wykonawca zobowiązany jest do koordynacji Wdrożenia z Dostawcą ERP w celu

dokonania Integracji.

2. Koordynacja działań powinna polegać na wzajemnej współpracy Wykonawcy i Dostawcy ERP, w ten sposób, aby doszło do zintegrowania ZSI z ERP w możliwie najkrótszym czasie.

3. Wykonawca jest zobowiązany do ustalenia terminów przeprowadzenia integracji z Dostawcą ERP. Termin powinien przypadać w okresie 6 miesięcy od dnia Podpisania Protokołu Odbioru Końcowego lub w okresie wcześniejszym.

4. Jeśli Wykonawca i Dostawca ERP nie dojdą do porozumienia co do wspólnego terminu

dokonania Integracji, dzień rozpoczęcia Integracji wyznaczy Zamawiający. Dzień

rozpoczęcia Integracji wyznaczony przez Zamawiającego będzie dniem roboczym

przypadającym w okresie od dnia podpisania Protokołu Odbioru Końcowego do dnia

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

5. Zamawiający przekaże Wykonawcy i Dostawcy ERP dane kontaktowe do ich przedstawicieli.

6. Wykonawca zobowiązuje się współpracować w dobrej wierze z Dostawcą ERP w celu

dokonania Integracji. Po dokonaniu Integracji Zamawiający przystąpi do odbioru, który

zakończy się podpisem Protokołu Integracji przez przedstawicieli wykonawców i

Zamawiającego.

7. W przypadku braku możliwości dokonania Integracji, Zamawiający powoła komisję,

która zobowiązana będzie zidentyfikować przyczynę braku możliwości jej dokonania. W

skład komisji wchodzić będą po jednym przedstawicielu Zamawiającego, Wykonawcy i

Dostawcy ERP. Przewodniczącym komisji będzie przedstawiciel Zamawiającego.

8. Członkowie komisji, o której mowa w §16.7 Umowy powinni niezwłocznie, lecz nie

później niż w terminie 3 dni roboczych od dnia wyznaczonego zgodnie z §16.3 albo

§16.4 Umowy, przedstawić swoje stanowisko co do przyczyn braku możliwości

Integracji wraz z rekomendacją co do sposobu ich usunięcia i wskazaniem wykonawcy

odpowiedzialnego za podjęcie czynności umożliwiających Integrację.

Strona 202 z 204

§ 17 ZMIANY UMOWY

1. Zamawiający zgodnie z postanowieniami art. 144 ust. 1 ustawy Prawo zamówień

publicznych przewiduje możliwość zmiany postanowień zawartej umowy w stosunku

do treści oferty, na podstawie której dokonano wyboru Wykonawcy, jeżeli zmiany te

wynikły z okoliczności, których nie można było przewidzieć w chwili zawarcia umowy,

w szczególności w następujących sytuacjach:

1) gdy konieczność wprowadzenia modyfikacji wyniknie ze zmiany powszechnie

obowiązujących przepisów prawa, na mocy których na Zamawiającego lub Wykonawcę

nałożony zostanie obowiązek zrealizowania przedmiotu zamówienia w sposób różniący

się od zaoferowanego w ofercie lub obowiązek zmiany trybu wykonania zamówienia –

z zastrzeżeniem, że zmiana przepisów nie była uchwalona przed wszczęciem

postępowania o udzielenie zamówienia, w wyniku którego zawarto niniejszą umowę,

2) gdy podczas realizacji przedmiotu zamówienia zmianie ulegnie technologia

wykonywania robót na lepszą funkcjonalnie od technologii przewidzianej w ofercie, pod

warunkiem, iż nie spowoduje to zwiększenia kosztów realizacji zamówienia, a

Wykonawca przed zmianą umowy przedłoży Zamawiającemu do zaakceptowania

projekt przewidywanych zmian w inwestycji wraz z właściwym kosztorysem,

3) gdy podczas realizacji umowy wystąpią nieprzewidywalne na etapie zawierania umowy

okoliczności, które uniemożliwią zrealizowanie przedmiotu zamówienia w sposób

przewidziany w ofercie, a realizacja w tym zakresie zamówienia publicznego będzie

niemożliwa lub niecelowa ze względu na interes publiczny,

4) gdy podczas realizacji umowy wystąpią nieprzewidywalne na etapie zawierania umowy

okoliczności, które uniemożliwią zrealizowanie przedmiotu zamówienia w sposób

przewidziany w ofercie, a udzielenie w tym zakresie innego zamówienia publicznego w

trybie ustawy Prawo zamówień publicznych lub też będzie niemożliwe lub niecelowe ze

względu na interes publiczny,

2. Strony przewidują możliwość wprowadzenia – w formie pisemnego aneksu – zmiany

wysokości wynagrodzenia należnego Wykonawcy, w przypadku zmiany:

1) stawki podatku od towarów i usług,

2) wysokości minimalnego wynagrodzenia za pracę ustalonego na podstawie art. 2 ust. 3 –

5 ustawy z dnia 10 października 2002 r. o minimalnym wynagrodzeniu za pracę,

3) zasad podlegania ubezpieczeniom społecznym lub ubezpieczeniu zdrowotnemu lub

wysokości stawki składki na ubezpieczenie społeczne lub zdrowotne,

- jeżeli zmiany te będą miały wpływ na koszty wykonania zamówienia przez

Wykonawcę.

3. Jeżeli zaktualizuje się którakolwiek z podstaw do zmiany wynagrodzenia, o której

mowa w poprzednim ustępie, Wykonawca zobowiązany jest poinformować o tym fakcie

Zamawiającego w terminie do 15 dni od dnia wystąpienia przyczyn wpływających na

zmianę kosztów wykonania zamówienia oraz zobowiązany jest przedstawić

Zamawiającemu szczegółową kalkulację zmiany wysokości swojego wynagrodzenia,

opartą o przesłanki wymienione w ust. 1 Zamawiający może żądać od Wykonawcy

dodatkowych wyjaśnień w zakresie odnoszącym się do przedstawionej kalkulacji, w

tym w szczególności wyjaśnień, których celem jest jednoznaczne i wyczerpujące

wykazanie, w jaki sposób zmiany przepisów, o których mowa w art. 142 ust. 5 ustawy

Prawo zamówień publicznych, wpłynęły na koszt wykonania zamówienia. Ewentualna

zmiana wysokości wynagrodzenia będzie poprzedzona badaniem dokumentów

przedstawionych przez Wykonawcę i będzie następowała w oparciu o aneks do umowy.

4. Strona, która otrzymała wniosek, o którym mowa powyżej, ma prawo, w terminie 10 dni

roboczych, zażądać od drugiej Strony złożenia dodatkowych wyjaśnień. Jeśli Strona

Strona 203 z 204

zażądała dodatkowych wyjaśnień, to druga Strona jest zobowiązana złożyć je w terminie

10 dni roboczych od dnia otrzymania wniosku. Jeśli Strona, która otrzymała wniosek, o

czym mowa w powyższej treści, nie zażądała dodatkowych wyjaśnień, to następuje

zmiana Wynagrodzenia zgodna z wnioskiem, chyba że żądanie było oczywiście

bezzasadne lub zgłoszone w złej wierze.

5. Jeśli po otrzymaniu dodatkowych wyjaśnień Strona, która otrzymała wniosek, o którym

mowa w powyższej treści, nadal kwestionuje zasadność lub wysokość zmiany cen

wskazanej we wniosku, to Strony zobowiązują się przystąpić do negocjacji celem

polubownego załatwienia sporu. Negocjacje powinny zakończyć się w terminie do 60

dni od dnia złożenia wniosku.Brak porozumienia pomiędzy Stronami może stanowić

podstawę do wystąpienia na drogę sądową.

6. Żadna ze Stron nie może przelać na inny podmiot zobowiązań i uprawnień

wynikających z niniejszej umowy bez uprzedniej pisemnej zgody drugiej Strony (cesja

wierzytelności).

§ 18 POSTANOWIENIA KOŃCOWE

1. Umowa wchodzi w życie z dniem podpisania przez Strony. 2. Spory powstałe w wyniku realizacji Umowy rozstrzyga sąd powszechny właściwy

miejscowo dla siedziby Zamawiającego. 3. W sprawach nieuregulowanych w Umowie mają zastosowanie przepisy ustawy z dnia

29 stycznia 2004 roku - Prawo zamówieńpublicznych, Kodeksu Cywilnego oraz ustawy

o prawie autorskim i prawach pokrewnych, a także rozporządzeń wykonawczych. 4. Wykonawca nie może przenieść jakichkolwiek wierzytelności związanych z Umową na

rzecz osób trzecich bez uprzedniej pisemnej zgody Zamawiającego. 5. W zakresie w jakim nie narusza to przepisu art. 35 ustawy o finansach publicznych,

Strony zobowiązują się do utrzymania w tajemnicy i nie ujawniania, niepublikowania,

nieprzekazywania i nieudostępniania w żaden inny sposób osobom trzecim,

jakichkolwiek informacji, stanowiących tajemnicę przedsiębiorstwa w rozumieniu

przepisów ustawy o zwalczaniu nieuczciwej konkurencji, które to informacje uzyskają w

trakcie lub w związku z realizacją Umowy, o ile informacje takie nie są powszechnie

znane, bądź obowiązek ich ujawnienia nie wynika z obowiązujących przepisów,

orzeczeń sądów lub decyzji odpowiednich władz, albo gdy przekazanie następuje na

rzecz podwykonawcy, który będzie realizował zobowiązania jednej ze Stron.

Obowiązkiem zachowania poufności nie jest objęty fakt zawarcia Umowy ani jej treść w

zakresie określonym obowiązującymi przepisami prawa.

6. Zamawiający zobowiązuje się do zapewnienia poufności udostępnionej dokumentacji technicznej ZSI.

7. Strony zobowiązują się zawrzeć oddzielną umowę o powierzenie przetwarzania danych osobowych w związku z wykonaniem Umowy przed powierzeniem przetwarzania takich danych.

8. Następujące załączniki stanowią integralną część Umowy:

1. Oferta;

2. SIWZ;

3. Wzór Protokołu Odbioru Etapu Wdrożenia;

Strona 204 z 204

4. Wzór Protokołu Odbioru Końcowego;

5. [ ]

6. [ ]

7. [ ]

9. Umowę sporządzono w czterech egzemplarzach.